MySQL: Performance e Índices - EXPLAIN e Otimização (Parte 4)

Este é o quarto artigo da série sobre administração de MySQL. Aqui vamos explorar técnicas essenciais de otimização, incluindo o uso do EXPLAIN, diferentes tipos de índices e estratégias para melhorar a performance das suas consultas.

O que é EXPLAIN?

Vamos entender na prática como é que o plano de execução pode mostrar para a gente, se uma consulta vai ser rápida ou demorada e para isso, a gente vai usar o MySQL como linha de comando.

Então, eu vou buscar aqui, vou abrir a minha janela de linha de comando e vou lá para o diretório do MySQL, fica em program files, MySQL, MySQL Server 8.0 e bin. E aí, para entrar no MySQL, é mysql -uroot -p, coloco a minha senha root e aí, pronto, tenho aqui o meu ambiente do MySQL por linha de comando.

Vou na minha base sucos_vendas e aí, vou executar uma daquelas consultas, vou começar pela consulta mais simples, que é a primeira, vou colar aqui. Opa, não copiei, copio, pronto. E aí, eu tenho lá o resultado da minha consulta pela linha de comando.

Usando EXPLAIN para Análise de Performance

Para a gente poder ver o plano de execução, a gente escreve EXPLAIN e a consulta que eu quero executar, ele me dá esses campos aqui, onde cada campo me dá uma pista de como vai se comportar essa consulta. Eu vou ter uma linha para cada tabela envolvida na query que está sendo analisada pelo EXPLAIN.

Como no caso aqui, esse SELECT, somente utilizou uma tabela, que eu chamei de tabela A, somente a tabela A está envolvida nessa consulta, mas tem uma outra forma de a gente ver esse resultado, se eu botar aqui no final da linha um "\G", eu tenho o meu resultado, invés de no formato de tabela, sequencialmente, fica até mais simples de a gente poder estar olhando.

Formatos de Saída do EXPLAIN

Agora, eu tenho um terceiro formato do EXPLAIN, que é o meu preferido, que é o seguinte, eu coloco aqui, "FORMAT=JSON", ao colocar esse comando, eu vou ter a minha resposta assim. Aparentemente, você pode achar que isso é mais confuso, mas é que eu tenho informações mais interessantes nessa consulta.

Uma delas é essa aqui, o query_cost, o query_cost, ele é basicamente o custo da consulta. Você vai me perguntar: "Que unidade de medida é essa? É segundo? É hora? É minuto?", na verdade é uma unidade indefinida. Pense no seguinte, quanto menor o query_cost, mais rápida vai ser a consulta.

Então o seu objetivo é ir arrumando a consulta, de tal maneira que o query_cost seja o menor possível. Aqui, por exemplo, tem o numero de linhas que vão ser examinadas e basicamente, esses dois valores mostram o custo de leitura e de escrita da consulta.

Conceitos de Índices

Vamos falar um pouquinho sobre índices. O conceito de índice baseia-se assim, que... se eu for pesquisar um conjunto de dados, buscar um dado dentro de uma lista de informações, onde esse dado que eu estou buscando, se ele está previamente classificado, ordenado, é muito mais fácil achar esse dado, do que se eu tivesse procurando essa informação numa lista totalmente espalhada.

Porque assim, se eu tenho uma coisa ordenada de forma alfabética, por exemplo e eu vou procurar por um nome, por exemplo, Pedro, eu já buscar direto na letra "P", porque eu sei... se ela está ordenada, eu tenho essa busca de uma maneira mais inteligente, mais rápida, do que se eu for buscar esse nome dentro de uma listra totalmente bagunçada.

Como Funcionam os Índices

Então, o índice, ele serve para ajudar a gente na busca dessas informações, então é uma estrutura que auxilia a tabela a achar dados. Quando o MySQL, ele cria um índice, seja esse índice uma ou mais colunas, ele vai e cria para a gente uma copia dessa coluna, numa outra estrutura, mas de forma ordenada.

O que nós estamos vendo aqui em cima, seria a representação de como funciona o índice. Atenção, numa tabela do tipo MyISAM, a informação que é colocada na tabela, ela está apresentada de forma, como eu posso dizer, assim... de forma... na ordem com que os registros forem incluídos.

Então, eu tenho aqui no canto uma tabela de livros, onde o primeiro livro que foi inserido foi o livro 7-234-5, deixa eu só colocar aqui o apontador. Pronto. Foi o livro 7-234-5, Sob Dica e esse é o autor.

Depois, eu inclui esse outro ID, com esse no título e esse autor e o de baixo, depois, foi o terceiro livro a ser colocado nessa base de dados. Se eu quiser procurar pelo livro 2-345, se eu não tiver a estrutura de índice, eu tenho que percorrer essa tabela e ir procurando, até acha-la.

Estrutura de Índices no MyISAM

Mas aí, em tabelas MyISAM, que é o exemplo que eu estou mostrando aqui em cima, quando eu crio um índice, ele cria uma estrutura a parte, onde ele coloca a coluna, onde o índice está sendo representado, já de forma ordenada e eu tenho do lado uma estrutura que diz a posição daquela coluna dentro da tabela.

Então, por exemplo, o 2-2315 é o segundo registro, está aqui, é o segundo registro. O 7234-5, é o primeiro registro, está aqui em cima. Então, esse aqui seria a tabela de índices, quando a gente utiliza o ID como índice.

Agora, se tu quiser criar índices para a coluna título ou para a coluna autor, eu vou ter outras estruturas, onde o campo está ordenado de forma alfabética e eu tenho como referência o registro que está aqui em cima. Então, nesse caso aqui, eu tenho uma tabela e três índices.

Custos e Benefícios dos Índices

Não importa se o índice é de uma coluna que é chave primária ou não, relembrando, chave primária é aquela chave que a tabela tem, onde nenhum registro pode se repetir com aquela mesma chave. Aqui no caso, a chave primária é ID, mas a representação do índice dentro de uma tabela MyISAM, funciona da mesma maneira que os outros índices.

Agora, essa estrutura, ele tem um certo custo. Apesar de o índice facilitar o processo de busca, se eu, por acaso, for incluir um novo registro na minha tabela, eu vou ter que estar colocando, atualizando esses índices, toda a vez que eu modificar a minha tabela.

E isso de uma certa maneira, é custoso. Imagine, eu tenho aqui três índices, toda a vez que eu modificar ou incluir alguém, quando essa operação for feita nessa tabela, eu tenho que também estar atualizando as tabelas de índice.

Então, claro, se eu tiver uma tabela muito grande dentro do MySQL e se eu tiver muitos índices associados a essa tabela, toda a vez que eu for incluir, alterar ou excluir ou... um registro daquela tabela, eu vou ter um problema de performance, porque essa operação vai ficar muito mais lenta, porque a cada modificação da tabela, eu vou ter que alterar os índices.

Índices no InnoDB

Então, isso é um peso de benefício e custo, que você deve estar meio que prestando atenção, sempre que você for projetar os índices e tudo mais, dentro da tabela que você vai usar na base de dados.

Agora, nas tabelas do tipo InnoDB, apesar de o índice também ser de uma certa maneira custoso ao atualizar a tabela, a estrutura de índices na InnoDB, ela é um pouquinho diferente da apresentada aqui.

Então, vamos passar para o próximo slide, aqui está a representação dos índices numa InnoDB. Na InnoDB, há uma distinção entre o índice que está associado a chave primária e ao que não é chave primária. Quando eu tenho um índice associado a chave primária, ele faz parte da tabela de dados.

Então, aqui no caso, note, apesar de a minha tabela ter uma ordem natural de inclusão dos dados, ao fazer isso, uma tabela InnoDB já organiza a própria tabela usando o índice da chave primária. Então, é como se o índice e a tabela de dados, para a chave primária, fossem uma coisa só.

Algoritmos de Busca: HASH vs BTREE

BTREE - Árvore Binária Balanceada

Para entender bem como é que funciona esses algoritmos, a gente precisa primeiro entender um conceito, um pouco diferente, que é o conceito de uma árvore binária. Então, o que eu estou vendo aqui em cima é uma árvore binária.

Quando a gente monta essa árvore binária, a gente garante sempre que todos os valores que estão a esquerda do nó, são valores menores do que o valor do nó e todos os valores que estão a direita do nó, são valores maiores do que o nó.

Então, se a gente olhar aqui esse exemplo, essa figura, note o seguinte, todos os valores que estão a esquerda do 27, são nós menores que 27 e todos que estão a direita do 27 são nós maiores que 27. Então, se eu estiver olhando o 27 e quiser buscar um numero menor que 27, eu vou para o lado esquerdo.

Se eu quiser achar um numero maior do que o 27, eu vou para o lado direito, se eu quiser achar o próprio 27, eu não preciso ir para lugar nenhum, já o encontrei.

Como Funciona a Busca BTREE

Agora, se a gente olha o foco do outro nó, por exemplo o 14, todos os nós que estão a esquerda 14, são menores do que 14 e todos que estão a direita do 14, são maiores do que o 14.

Então, por exemplo, então eu estou vendo... vamos fazer um exemplo aqui hipotético, digamos que eu queria buscar o numero 19, como é que o algoritmo funciona? Ele vai no 27, 19 é maior que 27? Não, é menor, então eu sei que está tudo do lado esquerdo.

Eu esqueço os nós do lado direito. Aí, eu passo para o nó de baixo que é o 14, o 14, ele é menor ou maior que 19? "Ah, ele é maior que 19", então eu sei que o 19 está a direita do 14, eu não... tudo o que estiver a esquerda do 14, eu não vou mais, aí eu desço mais um nível.

Aí, eu acho o próprio numero 19. Agora, o que que é uma BTREE, uma BTREE é uma árvore binária balanceada, por isso a letra B, de balance, qual é a diferença então de uma árvore binária normal e uma árvore binária balanceada?

Vantagens da BTREE Balanceada

Na árvore binária normal, quando eu monto esse algoritmo de esquerda e direita, eu não garanto para vocês que a árvore tem os mesmos nós, tanto para um lado, quanto para o outro. Já numa árvore balanceada, a gente meio que garante que os nós estão bem distribuídos, ou seja, normalmente o topo da árvore binária é a mediana dos números, das opções que eu estou procurando.

E aí, eu garanto que se eu for buscar para o lado direito ou buscar para o lado esquerdo, tanto faz, eu vou ter mesmos custos para achar um determinado numero.

Eficiência Matemática da BTREE

O algoritmo de BTREE, ele é matematicamente eficiente, se eu tiver, por exemplo, 4 bilhões de nós, por exemplo. Se você olhar matematicamente, no máximo eu vou precisar fazer 32 buscas para achar qualquer numero num algoritmo de BTREE, por que?

Porque assim, tem 4 bilhões, então o nó do meio da árvore balanceada, vai ser o numero 2 bilhões. Então, se eu quero achar um numero, a primeira coisa, digamos que eu queira achar o numero 1450, eu vou no 2 milhões, eu vejo esse numero está a direita ou a esquerda?

Está a esquerda. Aí, no segundo nível a esquerda do 2 milhões, eu tenho um nó central que é um milhão. Aí, eu vou testar, estou no segundo nível. O numero está a esquerda do um milhão ou a direita de um milhão? "Ah, está a esquerda".

Aí, o nó de baixo do grupo da esquerda, vai estar em 500 milhões e assim por diante e aí, até eu descer, depois de descer 32 níveis, eu vou conseguir chegar ao grupo de nós, que o numero que eu estou buscando o existe, por isso que é uma consulta que requer... é um algoritmo que requer um esforço computacional para achar qualquer valor bem pequeno.

HASH - Algoritmo de Hash

Do que, por exemplo, eu percorrer os 4 bilhões e saber quem é numero, esse numero é o que eu quero? Não. É o que eu quero? Não. Lembrando que essa busca da árvore binária, seria a busca para eu achar o valor que e usado como critério do índice.

Se eu tenho um índice por estado, então eu estou usando o método BTREE para achar o estado dentro da lista ordenada. Quando eu achar o estado, aí eu vejo a referência, se for MyISAM, a referência é pela linha da tabela, se for InnoDB, essa referência é a PK e aí, vou na tabela e consigo capturar todos os dados que eu estou procurando.

Então, esse aqui é o conceito do algoritmo BTREE. O algoritmo HASH, ele é um pouquinho mais difícil de entender, até eu mesmo tenho um pouco de dificuldade, porque ele tem algumas coisas meio misteriosas embutidas nele.

Como Funciona o HASH

Algoritmo de HASH, ele é usado, não somente para índices, mas o HASH é usado muito para criptografia, para armazenagem de senhas e o algoritmo de HASH é um algoritmo matemático que permite que a gente pegue um valor de texto, um string, independente do seu tamanho, se é uma string de um caracteres ou de 100 caracteres.

A gente reduz isso a uma palavra de tamanho fixo, então é como se a gente, por exemplo, essa tabela, eu tenho lá o seguinte, eu tenho uma string, aqui tem um montão de letras e aplicando o algoritmo de HASH nele, eu transformo essa string em outros caracteres de string com tamanho fixo.

Mas, se eu por acaso pegar uma outra string, um pouco menor, eu consigo reduzir ele para uma string do mesmo tamanho que o anterior, isso vai depender dos parâmetros que eu estou colocando no HASH. E aí, o algoritmo de HASH tenta tanto transformar o string em HASH, como pegar o HASH e transformar de volta para string.

Aplicação do HASH em Índices

Os valores que foram transformados pelo HASH, são valores completamente embaralhados, que eu não consigo entender, por isso que esse algoritmo é muito usado em criptomoedas, criptografia, armazenar senha, essas coisas. Agora, como é que isso então ajuda a gente a achar alguém em uma tabela dentro do banco de dados?

Vou imagina um livro, um livro que você compra na banca, na livraria, numa banca de jornal. A primeira coisa que o livro tem, na primeira página dele tem um negócio chamado índice, que tem os capítulos e cada capitulo tem subtópicos e dentro de cada subtópico do capitulo, tem a página.

Então, eu só quero pegar aquele livro e eu quero entender um assunto, eu quero ler sobre tal coisa. Eu vou olhar o índice, eu vejo em que página o índice está, o assunto, desculpe, vou pegar o índice, acho o meu assunto, vejo a página que o assunto está.

E aí, eu vou naquela página e aí, eu começo a ler o texto, até encontrar o tópico que eu estou procurando. O HASH funciona da mesma maneira, como é que funciona isso? Então eu tenho o meu índice, lá com os meus dados num estrutura separada.

Usando Índices na Prática

Criando Índices

Agora, você vê que essa aula eu comecei falando de EXPLAIN, para a gente entender o plano de execução e como é que a gente consegue ver o custo de uma query, depois eu pulei de assunto e falei de índice, como é que funciona o índice, quais são os algoritmos de busca.

Agora, eu vou juntar as duas coisas, porque acontece muito o seguinte, o índice é um dos principais instrumentos para a gente melhorar o custo das queries, quer ver? Vamos fazer um exemplo prático para ilustrar isso. Então, voltei aqui para o meu ambiente do meu MySQL em linha de comando e eu vou fazer o seguinte.

Eu vou pegar a seguinte consulta: "SELECT * FROM Notas_Fiscais WHERE Data_Venda = 20170101", deixa eu até selecionar essa linha, vou dar um "Ctrl + C", porque eu vou usar esse comando várias vezes, então vamos lá, eu vou rodar.

Eu trouxe lá uma série de linhas, todas elas são notas fiscais para o dia 27/01. Claro que internamente, o MySQL fez um plano de execução e executou a query, vamos ver como é que foi o custo dessa query? Se eu der um "EXPLAIN FORMAT = JSON", colocar o "\G", note que o custo da query foi 8849.05.

Medindo o Impacto dos Índices

Eu vou até aqui abrir um editor de texto e vou guardar isso daqui, essa query, ela custou para mim: 8849.05, eu vou até manter esse editor aberto e tudo que é comando que eu for executar, eu vou salvar aqui, para depois salvar esse arquivo e vocês terem como material para usar como complemento do curso.

Então eu rodei o EXPLAIN, "FORMAT = JSON" e query. Aí, nós vamos fazer o seguinte, nós vamos criar um índice, como é que eu crio um índice? Eu coloco o comando: "ALTER TABLE" o nome da tabela, "Notas_Fiscais ADD INDEX(Data_Venda)".

Por que que eu estou criando um índice para data_venda? Porque era o seguinte, aqui na minha consulta, note que a minha condição de filtro, que é WHERE, eu tenho que buscar na tabela, registros cuja a data da venda é 01 de janeiro de 2017.

Se eu tiver um índice pela data da venda, pelo campo data da venda, esse WHERE vai ser muito mais eficiente, porque invés de eu percorrer a tabela toda, eu vou lá no índice, acho aquela posição através do BTREE ou do HASH e pegando esse cara, se for MyISAM, eu vou pegar a posição dos registros que aquele cara pertence ou se for InnoDB, a posição da primary key da tabela_notas_fiscais.

E aí, eu consigo buscar as linhas da tabela que respeitam essa condição, por isso que, teoricamente, criar o índice vai funcionar, vai deixara query mais rápida, é o que vamos tentar ver se o plano de execução me mostra isso.

Verificando a Melhoria

Então, eu rodei esse comando aqui, o ALTER TABLE, vou executá-lo aqui. Então, pronto, o índice foi criado, vamos rodar agora o EXPLAIN novamente? Vou rodar de novo o EXPLAIN. Vamos ver o custo da query? Olha só o custo da query, caiu para 60.28, ou seja, depois que eu rodo a criação do índice, o custo da query caiu para 60.28, olha com o que o custo melhorou.

Para a gente ter certeza que realmente isso ajudou, note que... No Caso da consulta, onde o índice não havia sido criado, a gente tem aqui uma informação que é a seguinte: eu não tenho aqui... Eu tenho esse access_type = all, significa que ele vai acessar a tabela toda.

E eu não tenho uma informação aqui chamada key, porque ele não achou pelo critério que eu coloquei, que é WHERE, nenhuma chave que me ajude a achar aquela informação. Agora, já no JSON que a gente rodou com o índice, o access_type, mudou a ser ref e ele achou aqui uma chave possível data da venda e achou o índice aqui.

Esse aqui data_venda, é o índice que eu criei, então ele achou esse índice e falou: "Opa, eu vou usar esse índice porque é melhor do que eu não usar nada", enquanto que aqui em cima, ele não usou nenhuma chave, porque ele não encontrou.

Removendo o Índice para Comparação

Para a gente ver que realmente o índice está fazendo diferença, a gente pode, depois que criar o índice, a gente pode apagar esse índice, é: "ALTER TABLE Notas_Fiscais DROP INDEX Data_Venda". Eu agora, apaguei o índice, o índice não mais existe, o que acontece então se a gente rodar o EXPLAIN de novo?

Vou tirar aqui o espaço e aqui, vou no final, colocar o "\G". Pronto, agora melhorou. Note que o custo voltou ao valor 8994.33, "Puxa, mas o numero, está diferente daqui", na verdade esse custo da query é variável. Talvez vocês executando aí na máquina de vocês, vocês vão encontrar números diferentes.

Isso, como eu falei, também depende muito da memória, do hardware que você está usando e assim por diante, mas o importante é que os dois são muito maiores do que 60.28, isso mostra o quanto que um índice, ele ajuda na resolução desse... de melhorar a consulta.

Ferramenta mysqlslap

O que é mysqlslap

Antes de terminar a performance, eu gostaria de falar de uma ferramenta que já vem no MySQL chamado: mysqlslap, o que que essa ferramenta faz?

Ela simula acessos concorrentes a uma determinada consulta, assim, a gente aqui está vendo o custo da consulta, mas a gente consegue simular no MySQL... criar uma simulação, onde eu estou dizendo: "Vamos ver o que acontece se 100 usuários ao mesmo tempo, fazem 10 consultas nesta base, usando a consulta tal".

E aí, a gente pode usar ela com índice e ela sem índice e ver o resultado. Vamos começar, vamos pegar... vou criar aqui um script novo no Workbench, vamos pegar aquela consulta, "SELECT * FROM Notas_Fiscais WHERE Data_Venda = 20170101".

Comparando Performance com e sem Índices

A gente executou, se a gente olhar o plano de execução dela, a gente tem lá um Full Scan, porque não estou usando índice, lembra? Se a gente criar aqui "ALTER TABLE Notas_Fiscais ADD INDEX(Data_Venda)", então eu estou aqui criando um índice.

E aí, agora, com o índice, se eu executo de novo a consulta no Execution Plan, note que ele ficou aqui verde, porque ele conseguiu usar o índice para poder fazer aquela busca da data específica, então a consulta ficou muito mais rápida, mas vamos simulas o acesso de várias usuários concorrentes a essa consulta.

A gente vai comparar ela com essa daqui, com aquele 2, lembra? A tabela 1, 2, é uma tabela sem backup, sem FK e é claro, sem esse índice, porque o índice, eu criei na tabela normal, então vamos executar ela aqui. O custo original aqui deu 63.10, se eu executar consulta na tabela 2.

Vamos olhar aqui o Execution Plan, deu um valor de 8.831.73, quer dizer, ficou bem mais pesada a consulta, mas vamos ver o resultado disso num sqlslap. Então, para isso, eu vou voltar lá para o prompt do comando do Windows, no diretório Program Files, MySQL Server 8.0 bin e vou digitar mysqlslap -uroot -p.

Configurando o Teste de Carga

E aí, é o seguinte, eu vou entrar com dois parâmetros, um parâmetro é numero de interações e o outro parâmetro é numero de acesso concorrentes. Então, eu vou colocar aqui: concurrency, eu vou colocar 100, 100 acessos concorrentes, fazendo, iterations 10.

Então aqui, eu estou dizendo: 100 acessos concorrentes, 10 interações, aonde? No create... espera aí, que eu estou... iterations, vamos lá para o final... create_schema, aí é o meu schema que eu estou usando, sucos_vendas e "query=" e entre aspas duplas, eu vou colocar aquela nossa consulta.

Eu vou pegar primeiro a consulta com PK, com FK e com índice. Então, vamos ver se o comando ficou certo, ficou assim: "mysqlslap -uroot -p --concurrency = 100 --iterations=10 --create-schema, o nome do esquema, -query SELECT FROM Notas_Fiscais WHERE Data_Venda", tem a minha data da venda.

Resultados dos Testes

Vamos rodar. Vou entrar com a senha. Vamos esperar. Está lá, ele fez a minha simulação e note, em média, essa query vai retornar em 0.54 segundos o seu resultado, nas simulações, o maior tempo foi 1.28 e o menor tempo 0.23 segundos.

Agora, vou repetir o comando, só que agora, eu vou botar o 2, coloquei aqui o 2, para eu simular a outra tabela que não tem PK, não tem FK e não tem índice o data venda. Lembrando que o conteúdo das duas tabelas é o mesmo, porque uma foi fonte da outra.

Então, eu vou rodar. Entrei com a senha. Eu não sei se deu para sentir, mas inclusive, visualmente o tempo está maior, está demorando mais tempo para fazer a simulação. Terminou.

Note que o tempo médio foi de 0.54, para 2.6, o maior tempo que era 1.28, foi 3.44 e o menor tempo aqui foi 2.31, ou seja, o menor tempo na tabela que não tem chave primária, nem estrangeira, nem índice, o menor tempo ainda foi maior do que o maior tempo com os índices.

Estratégias de Otimização

Otimizando JOINs

Então, esse comando também é um comando muito legal para você testar, então, vale a pena você estar sempre usando o EXPLAIN para ver o custo da query e o mysqlslap para calcular o tempo. E aí, depois que a gente falou disso tudo, vem aquela pergunta: "Se eu acho uma query lenta, o que eu preciso fazer para que essa query fique rápida?".

Existem dezenas de procedimentos que podem ser feitos para a query melhorar, eu vou falar só de dois específicos. Primeiro, vamos pegar aquela query mais rebuscada, ela está aqui... A primeira coisa interessante, quando você tiver JOIN, que você garanta que haja índices nessas igualdades aqui.

Claro que normalmente os JOINs são feitos pelas PKs, então se a tabela não tem PK, cria PK, mesmo assim, se você fizer um JOIN com alguém que não tem índice, você cria o índice. Então, por exemplo, o código do produto, ele é índice na tabela de produtor e ele é índice na tabela de itens notas fiscais também, porque faz parte da PK.

Otimizando WHEREs

O numero a mesma coisa, mas digamos que tivesse fazendo um JOIN com data ou tivesse fazendo JOIN com um atributo da tabela que não é chave. Então é interessante você criar um índice para ela.

Outra dica importante é quando a gente fez essa ultima consulta, de quando eu tiver um WHERE, principalmente queries de igualdades, menor, maior, between, like, de também ter índice nesse campo que você utiliza para fazer o critério de filtro.

Então, assim, existem várias outras coisas que podem ser feitas para a query ficar mais rápidas, mas seguindo esses dois pontos, você já vai ter grandes ganhos. Índices nas igualdades dos JOINs e índice nos filtros de consulta, se você conseguir fazer isso, você vai conseguir um ganho enorme, em termos de resultados das suas consultas.

Conclusão

Performance e índices são fundamentais para o sucesso de qualquer aplicação MySQL. O EXPLAIN nos permite entender como o MySQL executa nossas consultas, enquanto os índices podem reduzir drasticamente o tempo de execução.

Pontos-chave:

Use EXPLAIN para analisar o plano de execução das suas consultas
Crie índices nas colunas usadas em JOINs e cláusulas WHERE
Escolha o algoritmo correto (BTREE vs HASH) para cada tipo de índice
Teste com mysqlslap para simular carga real
Monitore o query_cost para medir melhorias

Quando usar cada tipo de índice:

BTREE: Para comparações de igualdade, range queries e ordenação
HASH: Para comparações de igualdade simples (apenas MyISAM)
Índices compostos: Para queries com múltiplas condições

Na próxima parte desta série, exploraremos ferramentas avançadas de monitoramento e tuning, incluindo variáveis de configuração e análise de performance em tempo real.