A maioria dos problemas de performance que já resolvi em projetos legados não estava no código PHP — estava na modelagem do banco de MySQL — estava na modelagem do banco de dados. MySQL perdoa modelagem ruim até certo volume de dados; depois disso, cada consulta lenta vira um sintoma de uma decisão tomada anos antes.
Os erros que mais vejo
Ausência de índice em colunas usadas em WHERE e JOIN é o mais comum, mas não o único: campos que deveriam ser normalizados e não são, tabelas que armazenam listas como texto separado por vírgula, e relacionamentos que deveriam ser explícitos representados por convenção de nome de coluna. Cada um desses parece inofensivo com poucos registros e vira um problema real em produção.
Um exemplo clássico: uma tabela de alunos com uma coluna materias_interesse guardando "matemática,português,ciências" como texto puro. Funciona perfeitamente com 50 registros. Com 50 mil, cada consulta que precisa filtrar por matéria de interesse vira uma busca de texto lenta, sem índice possível — quando o correto seria uma tabela de relacionamento desde o início.
Como evito isso desde o início
Modelo pensando na pergunta que o sistema vai fazer ao banco com mais frequência, não só na entidade que estou representando. Um índice bem colocado no início custa segundos; adicionar depois, com a tabela já em produção e com milhões de linhas, custa uma manutenção inteira — e às vezes um período de indisponibilidade que poderia ter sido evitado.
Quando SQLite entra no lugar do MySQL
Nem todo problema de dados precisa da robustez do MySQL. Para testes automatizados e scripts internos, prefiro outra ferramenta — escrevi sobre esse critério em SQLite tem seu lugar. A régua de modelagem que descrevo aqui, porém, vale para qualquer banco relacional que você escolher.
