Já teve que otimizar consultas?

Sim, já tive que fazer isso. A otimização de consultas é uma parte importante do desenvolvimento de aplicações de alto desempenho.

Minha experiência inclui:

• Análise do plano de execução da consulta (EXPLAIN): Uso de EXPLAIN para entender como o banco de dados executa a consulta, quais índices são utilizados e onde surgem os gargalos.
• Criação e otimização de índices: Adição de índices apropriados às colunas frequentemente usadas e criação de índices compostos para acelerar filtragens, ordenações e junções. Remoção de índices não utilizados ou duplicados.
• Reescrita de consultas ineficientes:
  • Substituir SELECT * por seleção de colunas específicas.
  • Usar tipos de junções mais adequados (JOIN) em vez de subconsultas ou loops aninhados ao nível da aplicação.
  • Simplificar condições WHERE.
  • Evitar funções em condições WHERE em colunas indexadas.
  • Otimizar GROUP BY e ORDER BY.
• Normalização/denormalização: Aplicar normalização para reduzir redundâncias ou, em alguns casos, denormalização para acelerar a leitura de dados por duplicação ou criação de colunas agregadas (com precaução).
• Cache de resultados de consultas: Implementar cache a nível de aplicação ou usar mecanismos de cache de banco de dados (por exemplo, Redis, Memcached) para reduzir a carga na BD ao ler dados que se consultam frequentemente e mudam pouco.
• Limitação da seleção de dados: Uso de LIMIT para paginação ou para selecionar apenas a quantidade necessária de registros.
• Monitoramento e perfilagem: Uso de ferramentas de monitoramento (por exemplo, Percona Monitoring and Management, phpMyAdmin com Slow Query Log ativado) para identificar consultas lentas.

Exemplo de análise com EXPLAIN:

// Exemplo de consulta lenta sem índice na coluna status
SELECT * FROM orders WHERE status = 'pending' AND created_at < CURDATE();

// Análise do plano
EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND created_at < CURDATE();
// Pode mostrar uma varredura completa na tabela (ALL) ou não utilização de índice adequado.

// Adição de índice composto em ambas as colunas
CREATE INDEX idx_status_created_at ON orders (status, created_at);

// Análise após a criação do índice
EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND created_at < CURDATE();
// Espera-se que o tipo (type) mude para ref ou range, e Extra contenha "Using where;"