resumo
Recentemente eu encontrei um sql lento, encontrada no decurso da investigação após o conjunto de índices de bibliotecas e relacionamento sub-sub-mesa, resumiu a próxima pergunta.
problema
Durante a aplicação da saúde do inventário, encontramos uma sql lento
segue
select brandgoodid from brandgood_0020
where userid = xxx AND
brandgoodid in("xxx1","xxx2")Tabela estrutura, sub-tabela de acordo com o ID do utilizador .
CREATE TABLE`brandgood_0020` (
`brandgoodid` char(30) NOT NULL COMMENT ,
`user_id` int(10) unsigned DEFAULT NULL COMMENT '用户id',
`created` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
`last_modified` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`deleted` bit(1) NOT NULL DEFAULT b'0',
PRIMARY KEY (`brandgoodid`),
KEY `idx_userid` (`userid`) USING BTREE,
) ENGINE=InnoDB DEFAULT CHARSET=utf8
explainEle está tomando o ID de usuário encontrados no índice, um usuário aqui estão um lote de mercadorias, e terá um monte de brandgoodid, portanto, pode ser muito lento, porque você quer digitalizar um monte de chaves de índice para o valor brandgoodid filtro.
O índice de chave primária para escrever o SQL esperar que as pessoas vão, em vez de index 'ID de usuário'. Porque com o índice chave primária, o varrimento primário chave é N vezes (N indica o número de in).
análise
razões óbvias diretos
Nesta consulta mysql otimizador é enganosa, índice errado
na consulta muitas vezes afetam o julgamento de servidor mysql. A principal diferença é o número de valores na qual irá afectar número diferente de linhas de exploração, de modo que frequentemente aparecem selecção índice inconsistente. Antes também resumiu um no SQL necessariamente ter o índice que
resolver
Porque consulta utilizador brandgoodlid é definido em um determinado grupo de dimensão, um grupo brandgood correspondente está limitada, neste ramo, tipicamente menos do que 10. Portanto, este lugar usando o índice de chave primária, maior eficiência. Esta solução é, onde ela é necessária force indexpara forçar a distância índice primário.
propagação
Depois do índice de sub-tabela sub-biblioteca
Por direito do índice após a emissão da sub-biblioteca de sub-mesa, sub-mesa direto e sub-biblioteca não importa ah?
Porque quando a resolução de problemas, cometeu um erro. Depois de que o caminho para uma mesa brandgood_0020 específico, de acordo com brandgoodid directamente para consultar o índice chave primária. Alguns acreditam e base de dados distribuída (cassandra), é desses dados de índice chave tecla + partição um agrupamento. A chave pode bloquear o nó de agrupamento para particionar os dados, e então encontrar os dados correspondentes de acordo com o índice local.
Mas na verdade o sub-biblioteca de sub-tabela mysql não é o mesmo, o sub-tabela de chave não está indexado, mas a rota cliente. Responsável só para encontrar a tabela correspondente. Depois que a tabela é o mesmo que consultas de mesa única e lógica.
Porque o sub-tabela de chave não está indexado, mas a consulta é necessário tomar tabela de chave pontos, o que significa que depois da nossa sub-biblioteca de sub-tabela da tabela de índice construído em grande parte, ao índice comum, mesa sub-índice de chave chave + .
Caso contrário, a nossa consulta selecionar xx da mesa onde chave tabela de partição = xxx E a = xxx, não podia andar um índice comum. Você só pode ter um único índice. servidor de índices mysql single a ser confrontados com a seleção de índice problema.
Claro, não é absoluta, como os casos acima citados que eu. De acordo com esta ideia olhou para outros pontos de índice da tabela. o suficiente certeza, a maioria dos índices na tabela são o índice de não-articular, ou vir diretamente de um único índice da tabela de cópia. Estes índices são basicamente inútil, pois tudo que o índice de ID do utilizador.
problema de seleção Index
Por mysql seria índice errado, uma visão detalhada de 10 | MySQL Por que às vezes escolhem o índice errado
Julgamos neste caso por causa do número de linhas de varredura quando um problema.