Recentemente, encontrei uma mudança que o Percona Server implementou sobre o MySQL InnoDB normal. O novo recurso éinnodb_fast_checksum
O XtraDB pode usar um algoritmo de CPU mais eficiente, baseado em palavras de 4 bytes, o que pode ser benéfico para algumas cargas de trabalho (por exemplo, cargas de trabalho pesadas de gravação em servidores que podem executar muitas E/S).
Parece bom, mas gostaria de saber se há alguma carga de trabalho em que essa alteração teria um desempenho pior do que o método antigo.
A documentação continua dizendo:
O algoritmo original é verificado após o novo, portanto, você pode ter páginas de dados com somas de verificação antigas e páginas de dados com somas de verificação novas. No entanto, neste caso, você pode experimentar leituras lentas de páginas com somas de verificação antigas.
Portanto, supondo que você habilite innodb_fast_checksume reconstrua todas as suas tabelas InnoDB conforme sugerido para remover as somas de verificação antigas, há alguma situação em que a verificação extra nas somas de verificação antigas causaria degradação do desempenho?
Resumindo, há alguma razão para não correr innodb_fast_checksum?
A redação que você colou é muito específica:
Isso significa que ele ainda pode ler o checksum antigo, mas a partir de agora somente o Percona Server poderá ler seus dados. Isso é notado mais tarde aqui:
Você precisa colocá-lo em contexto - o InnoDB apenas verifica as somas de verificação quando lê uma página do dispositivo de armazenamento em bloco e a atualiza antes de descarregá-la de volta para o dispositivo de armazenamento. Enquanto estiver na memória, a soma de verificação não é mantida.
Por muitos anos, um IO para um disco levou algo da ordem de 5-10ms (1ms = 1/1000 de segundo). Calcular uma soma de verificação provavelmente leva algo em torno de 50us (1us = 1/1000000 de segundo). Não tenho os dados reais sobre o que é no caso do InnoDB, mas se você pesquisar no Google "Números que todos deveriam saber", provavelmente concordará que estou correto em uma ordem de grandeza.
Entre em uma era agora em que temos coisas como dispositivos flash Fusion-io, que no papel têm um tempo de acesso de aproximadamente 20 a 30 us, e você pode ver que reavaliar a soma de verificação faz sentido.
Meu conselho geral: não estrague sua compatibilidade com versões anteriores do MySQL, a menos que você realmente precise. A maioria das pessoas ainda não precisa disso.
Morgan está correto. A menos que você esteja executando um dispositivo extremamente rápido com latência de acesso muito baixa, o acesso de E/S diminuirá o tempo de soma de verificação e ativar somas de verificação rápidas fará apenas uma diferença insignificante.