Otimize a estrutura do banco de dados

Otimizar o tamanho dos dados

→ Reduzindo a quantidade de dados gravados e lidos no disco

→ Menos memória principal enquanto seu conteúdo está sendo processado ativamente durante a execução da consulta

→ Resulta em índices menores que podem ser processados ​​mais rapidamente

Colunas da tabela

• Use os tipos de dados mais eficientes (menores) possíveis
• Declarar colunas como NOT NULL se possível → melhor uso de índices e eliminação de sobrecarga para testar se cada valor é NULL.

Índices

• O índice primário de uma tabela deve ser o mais curto possível
• Crie apenas os índices necessários para melhorar o desempenho da consulta. Os índices são bons para recuperação, mas tornam as operações de inserção e atualização mais lentas.
• pesquisando em uma combinação de colunas → crie um índice composto
• a primeira coluna do índice deve ser aquela com mais duplicatas → para obter melhor compactação do índice.

Junta

• Declarar colunas com informações idênticas em tabelas diferentes com tipos de dados idênticos → mesmo tipo de dados
• Mantenha os nomes das colunas simples,

Normalização

• Normalmente, tente manter todos os dados não redundantes
• Se a velocidade é mais importante que o espaço em disco e os custos de manutenção de manter múltiplas cópias de dados

Otimizar tipo de dados

• Para IDs exclusivos ou outros valores que podem ser representados como strings ou números, → os valores numéricos podem ser armazenados em menos bytes do que as strings correspondentes, mais rápido e ocupa menos memória para transferi-los e compará-los.
• Ao comparar valores de colunas diferentes, declare essas colunas com o mesmo conjunto de caracteres e agrupamento sempre que possível → evite conversões de string
• Para valores de coluna com tamanho inferior a 8 KB, use VARCHAR binário em vez de BLOB. As cláusulas GROUP BY e ORDER BY podem gerar tabelas temporárias, e essas tabelas temporárias podem usar o mecanismo de armazenamento MEMORY se a tabela original não contiver nenhuma coluna BLOB .
• Se uma tabela contém colunas de string e não é acessada com frequência → dividir para outra tabela e juntar → Quando o MySQL recupera qualquer valor de uma linha, ele lê um bloco de dados contendo todas as colunas daquela linha (e possivelmente outras linhas adjacentes). Manter cada linha pequena, com apenas as colunas usadas com mais frequência, permite que mais linhas caibam em cada bloco de dados.
• Ao usar um valor gerado aleatoriamente como chave primária em uma tabela do InnoDB, prefixe-o com um valor crescente, como a data e hora atuais, se possível.
• Para uma tabela com várias colunas, para reduzir os requisitos de memória para consultas que não usam a coluna BLOB, considere dividir a coluna BLOB em uma tabela separada e referenciá-la com uma consulta de junção quando necessário
• • Como os requisitos de desempenho para recuperar e exibir um valor BLOB podem ser muito diferentes de outros tipos de dados, você pode colocar a tabela específica do BLOB em um dispositivo de armazenamento diferente ou até mesmo em um separado instância de banco de dados. Por exemplo, para recuperar um BLOB pode ser necessária uma grande leitura sequencial de disco, mais adequada a um disco rígido tradicional do que a um dispositivo SSD.
• Em vez de testar a igualdade em uma string de texto muito longa, você pode armazenar um hash do valor da coluna em uma coluna separada, indexar essa coluna e testar o valor do hash nas consultas. (Use a função MD5() ou CRC32() para produzir o valor hash.)

Otimizando instruções SQL

Achamos útil analisar uma consulta com baixo desempenho em duas etapas:

• Descubra se seu aplicativo está recuperando mais dados do que você precisa. Isso geralmente significa que ele está acessando muitas linhas, mas também pode estar acessando muitas colunas.
• Descubra se o servidor MySQL está analisando mais linhas do que o necessário.

Otimizando instruções SELECT

• Evite usar funções em predicados
• Evite usar um curinga (%) no início de um predicado
• Use DISTINCT e UNION somente se necessário