Temos um servidor MySQL instalado em duas máquinas diferentes, um servidor de teste e um servidor de produção, ambas janelas, que são usadas por um aplicativo da web.
O problema é que existem enormes diferenças de desempenho entre as duas máquinas ao executar algumas consultas (o servidor de produção é o mais lento). A versão do MySQL nos dois servidores é a mesma, até os arquivos de configuração são os mesmos (a única diferença é o caminho dos dados e o fato de o servidor de produção não registrar nada além dos erros). A diferença de desempenho de que estou falando é 3 ou 4 ordens de magnitude maior (por exemplo, uma consulta no servidor de teste é executada em 0,2 s, enquanto que no servidor de produção é executada em 84 s).
As consultas incorretas fazem uso extensivo de cláusulas com "WHERE [...] IN [...]", que é meu entendimento de que elas geralmente são muito lentas e devem ser substituídas por JOINs. No entanto, a versão do MySQL que estamos usando é a 5.6.19, que otimiza essas consultas automaticamente, é por isso que elas executam rapidamente no servidor de teste (e fazem parte de um programa que não podemos alterar, por isso não podemos otimizá-las manualmente) de qualquer forma).
Como eu disse, a instalação e configuração do MySQL são idênticas, por isso não entendo onde o problema pode estar. Por um lado, suspeito que deva ser algum tipo de problema de configuração, pois o programa e o banco de dados são os mesmos; por outro lado, isso não faz sentido, pois a configuração é idêntica.
Alguns dados nos servidores:
Servidor de teste:
- Intel Core 2 Quad Q9400 a 2.66GHz
- 8GB RAM
- Windows Server 2008 R2 Standard
Servidor de produção:
- Intel Xeon E5530 a 2.40GHz
- 5GB RAM
- Windows Server 2012 R2 Standard
Edit: Eu esqueci de dizer uma coisa importante: há mais consultas sendo executadas que usam as cláusulas "WHERE ... IN" para as "ofensivas". Eles são executados rapidamente nas duas máquinas, o que sugere que eles estão sendo otimizados corretamente pelo MySQL. O fato de algumas consultas serem otimizadas quando outras não são um mistério para mim, se esse for o problema real, não tenho certeza.
Editar # 2: Aqui está o arquivo de configuração para os dois servidores: http://pastebin.ca/2834906
Edit # 3: Aqui está o EXPLAIN de uma das consultas lentas: https://mariadb.org/ea/v36zj O EXPLAIN é exatamente o mesmo no teste e no produto. A consulta em si está aqui: http://pastebin.com/VXgBxXmt Foi formatada com um autoformador, portanto, talvez não seja muito clara. Como você pode ver, é bastante longo e complexo. Ele não foi gerado manualmente, eles são gerados automaticamente pelo software, que usa um dialeto do SQL padrão com algumas funções.
Além disso, mais informações: corrigimos o problema temporariamente, reduzindo os dados no servidor de produção e removendo a maioria dos dados antigos no banco de dados, que não serão usados. Esta não é uma solução, é claro, já que precisamos também dos dados antigos e será um problema no futuro. O banco de dados não é tão grande: o banco de dados completo tem 1308MB, a versão reduzida atualmente em produção é 332MB.
ATUALIZAÇÃO: RESOLVIDO ??
Eu acho que resolvi o problema. Ainda não testei, já que o servidor de produção está realmente sendo usado, mas o possível problema foi o parâmetro "innodb_buffer_pool_size", definido como 182M. Na verdade, a linha no arquivo de configuração mostra: innodb_buffer_pool_size = 321, que é um erro, pois não possui o prefixo da unidade, fornecendo um valor inválido (o mínimo é 5242880 de acordo com os documentos) e colocando-o no valor anterior . Este valor no servidor de teste foi definido nos 321M desejados.
Como eu disse, não testei completamente. O que fiz foi reduzir o valor nos testes e experimentar o aplicativo. Tudo fica mais lento, e a consulta específica que publiquei é executada em 3 minutos.
Eu testei um valor mais sensato de 3Gb, que eu não sei se é uma boa idéia, então se alguém tiver algum comentário sobre esse valor, eu aprecio isso.
Minhas conclusões, o "valor sensato" do 3Gb e as informações que usei para isso vêm dessas duas postagens, principalmente da segunda:
Consulta MySQL, 2 servidores similares, diferença de 2 minutos nos tempos de execução
Qual o tamanho do mysql innodb_buffer_pool_size?
Vou postar os resultados "reais" quando atualizarmos os valores no servidor de produção.
Obrigado a todos.
RESOLVIDO
Então, finalmente testamos isso no prod, e foi o problema que comentei anteriormente. Coloquei o valor de innodb_buffer_pool_size em 321M, que é o valor recomendado pelo fornecedor do SDK que usamos, embora, de acordo com os links anteriores, deva ser em torno de 3G para um banco de dados desse tamanho e uso.
Eu ainda tenho uma dúvida: o valor de 321 era um valor inválido (muito pequeno), então o MySQL assumiu outro valor. Minha suspeita é que ele pegou o número válido anterior, 321M no teste e 182M no prod, daí as diferenças de velocidade. É apenas por curiosidade, mas eu gostaria de saber se isso está certo.
Obrigado a todos novamente pela ajuda.