Entendendo Índices no MySQL:Parte Dois

Esta postagem do blog é a segunda parte da série de blogs sobre índices no MySQL. Na primeira parte da série de postagens do blog sobre índices MySQL, abordamos muitas coisas, incluindo o que são, o que fazem, quais são seus tipos, como escolher tipos de dados ideais e conjuntos de caracteres MySQL para índices que você usa . Examinamos as vantagens e desvantagens de usar índices no MySQL; dissemos a você como escolher o melhor índice a ser usado, como melhorar o desempenho da consulta e garantir que o MySQL use seus índices, quantos índices você deve ter. Também passamos por algumas considerações relacionadas aos mecanismos de armazenamento. Esta postagem do blog entrará em mais detalhes sobre alguns dos conteúdos que discutimos na primeira parte da série. Começaremos com a correlação entre índices e mecanismos de armazenamento no MySQL.

Indexes e mecanismos de armazenamento no MySQL

Como já mencionamos em uma postagem anterior do blog, pode haver alguns tipos de limitações para índices e outras coisas se você usar determinados mecanismos de armazenamento no MySQL. Aqui estão alguns deles - agora vamos definir o que são alguns deles (alguns deles foram abordados na primeira parte da série de blogs, então, se estiver faltando algo, provavelmente está lá), então cobri-los com mais profundidade análise:

• De acordo com a documentação do MySQL, o número máximo de índices, o tamanho máximo da chave e o tamanho máximo do índice são definido por mecanismo de armazenamento. Como já mencionamos em um post anterior do blog, o número máximo de índices por tabelas MyISAM e InnoDB é 64, o número máximo de colunas por índice em ambos os mecanismos de armazenamento é 16, o comprimento máximo de chave para InnoDB é 3500 bytes e o máximo o comprimento da chave para MyISAM é de 1000 bytes.
  

• Você não pode usar CREATE INDEX para criar uma PRIMARY KEY - em vez disso, use ALTER TABLE.
  

• As colunas BLOB e TEXT podem ser indexadas apenas para tabelas que executam os mecanismos de armazenamento InnoDB, MyISAM e BLACKHOLE.
  

• Se você indexar apenas um prefixo da coluna, lembre-se de que o suporte ao prefixo e seu comprimento também são dependente de mecanismos de armazenamento. Um prefixo pode ter até 767 bytes para tabelas InnoDB que usam o formato de linha REDUNDANT ou COMPACT, mas para formatos de linha DYNAMIC ou COMPRESSED o limite de comprimento do prefixo é aumentado para 3072 bytes. Para tabelas MyISAM, o limite de comprimento do prefixo é de 1000 bytes. O mecanismo de armazenamento NDB não oferece suporte a prefixos.
  

• Se um modo SQL estrito estiver ativado e o prefixo do índice exceder o tamanho máximo do tipo de dados da coluna, CREATE INDEX lançará um erro. Se um modo SQL estrito não estiver habilitado, CREATE INDEX produzirá um aviso. Se um UNIQUE INDEX for criado, ocorrerá um erro.
  

• Em geral, o MySQL só permite criar até 16 índices em uma determinada tabela.
  

• Se você estiver usando um índice PRIMARY KEY, só poderá ter uma chave primária por tabela. FULLTEXT, UNIQUE INDEXes e INDEXes não têm essa limitação.
  

•  Se você estiver usando índices FULLTEXT, lembre-se de que eles só podem ser usados ​​para mecanismos de armazenamento InnoDB ou MyISAM e para colunas CHAR, VARCHAR ou TEXT. Lembre-se também de que o MySQL só usa índices FULLTEXT quando as cláusulas MATCH() AGAINST() são usadas e que você pode realmente ter um índice e um índice de texto completo na mesma coluna ao mesmo tempo, se desejar, e que os índices FULLTEXT têm seus próprio conjunto de palavras irrelevantes, cada uma específica para os mecanismos de armazenamento em uso.
  

• Os índices B-Tree podem ser úteis se você usar consultas LIKE que começam com um curinga, mas apenas em determinados cenários.
  

Conhecer essas limitações de índice deve ser útil se você estiver tentando entender como os índices no MySQL funcionam. O que é ainda mais importante entender é o fato de que você deve verificar se seus índices são realmente usados ​​pelo MySQL. Nós abordamos isso brevemente na primeira parte desta série (“Como escolher o melhor índice a ser usado?”), mas não dissemos a você como verificar se seus índices são realmente usados ​​pelo MySQL. Para fazer isso, verifique seu uso usando EXPLAIN - quando EXPLAIN é usado junto com uma instrução explicável, o MySQL exibe informações do otimizador sobre o plano de execução da instrução.

Considerações de CHAVE PRIMÁRIA

Algumas das considerações básicas relacionadas aos índices PRIMARY KEY no MySQL incluem o fato de que eles são usados ​​principalmente para identificar registros em uma tabela e são frequentemente usados ​​com valores AUTO_INCREMENTing, o que significa que eles podem ser muito úteis se você está criando, digamos, campos de ID. Os campos PRIMARY KEY devem conter valores exclusivos e não podem conter valores NULL.

Correspondência de um prefixo de coluna

Os índices também podem corresponder a um prefixo de coluna. Essa abordagem para índices pode ser útil se suas colunas forem colunas de string e você achar que adicionar um índice em toda a coluna consumiria potencialmente muito espaço em disco. Seus índices podem corresponder a um prefixo de coluna assim:

ALTER TABLE demo_table ADD INDEX index_name(column_name(length));

A consulta acima adicionaria um índice index_name em uma coluna chamada column_name apenas para um prefixo de coluna definido. Para escolher uma boa quantidade de comprimento para indexar, certifique-se de que o uso do prefixo maximize a exclusividade dos valores na coluna:encontre o número de linhas na tabela e avalie diferentes comprimentos de prefixo até atingir a exclusividade de linhas desejada.

Índices FULLTEXT no MySQL

Índices FULLTEXT no MySQL são completamente diferentes. Eles têm muitas limitações exclusivas (por exemplo, o InnoDB tem uma lista de palavras irrelevantes composta por 36 palavras enquanto a lista de palavras irrelevantes MyISAM é composta por 143 palavras), eles também possuem modos de pesquisa exclusivos. Alguns deles incluem um modo de linguagem natural (para ativar esse modo de pesquisa, execute uma consulta de pesquisa FULLTEXT sem modificadores), você também pode expandir sua pesquisa (para fazer isso, use o modificador WITH QUERY EXPANSION - esse modo de pesquisa realiza o pesquisa duas vezes, mas quando a pesquisa é executada pela segunda vez inclui alguns registros mais relevantes da primeira pesquisa - frequentemente usado quando um usuário tem conhecimento implícito de algo), para pesquisar com operadores booleanos use o modificador IN BOOLEAN MODE. Os índices FULLTEXT também só serão usados ​​se a consulta de pesquisa consistir em um mínimo de três caracteres para InnoDB e um mínimo de quatro caracteres para MyISAM.

Usando índices B-Tree com curingas

Os índices também são usados ​​com frequência se você estiver criando algo semelhante aos mecanismos de pesquisa. Para isso, você geralmente deseja pesquisar apenas uma parte de um valor e retornar os resultados - é aqui que entram os curingas. Uma consulta simples usando um curinga usa uma consulta LIKE e o sinal % para significar "qualquer coisa" após o texto. Por exemplo, uma consulta como essa buscaria resultados começando com a palavra “pesquisar” e tendo qualquer coisa depois dela:

SELECT * FROM … WHERE demo_column LIKE ‘search%’;

Uma consulta como essa buscaria resultados começando com qualquer coisa, tendo a palavra “pesquisar” e tendo qualquer coisa depois dela:

SELECT * FROM … WHERE demo_column LIKE ‘%search%’;

Mas aqui está um problema - a consulta acima não usará um índice. Por quê? Porque ele tem um curinga no início de si mesmo e o MySQL não consegue descobrir o que a coluna precisa para começar. É por isso que dissemos que os índices curinga têm seu lugar, mas apenas em cenários específicos - ou seja, cenários em que você não tem um curinga no início de sua consulta de pesquisa.

Usando ClusterControl para monitorar o desempenho de consultas

Além de usar EXPLAIN, você também pode usar o ClusterControl para monitorar o desempenho de suas consultas:ClusterControl fornece um conjunto de recursos avançados de monitoramento e relatórios que permitem acompanhar o desempenho de suas instâncias de banco de dados e consultas . Por exemplo, clique em um cluster e você verá uma guia “Query Monitor”. Clique nele e o ClusterControl permitirá que você observe o status de suas consultas em suas instâncias de banco de dados:

Esta parte do ClusterControl permite visualizar uma lista dos principais executando consultas ao mesmo tempo que permite filtrá-las. Por exemplo, se você sabe que há pouco tempo você executou uma consulta que consistia em @@log_bin, você pode simplesmente pesquisar o termo e o ClusterControl retornará uma lista de resultados:

Como você provavelmente notou, você também pode filtrar consultas por hosts que você usa ou por ocorrências, você também pode optar por ver um conjunto de linhas, por exemplo, 20, 100 ou 200. O ClusterControl também informará quando a consulta foi vista pela última vez, qual foi seu tempo total de execução, quantas linhas ela retornou, quantas linhas ele examinou e assim por diante. O ClusterControl pode ser útil se você quiser observar como seus índices são realmente usados ​​pelas instâncias MySQL, MariaDB, MongoDB, PostgreSQL ou TimescaleDB.

Resumo