Simplemente debe deshabilitar la caché de consultas con
[mysqld]
query_cache_size = 0
y luego reinicie mysql. ¿Por qué sugeriría eso?
Query Cache siempre se topará con InnoDB. Sería bueno que MVCC de InnoDB permitiera que las consultas se atendieran desde el caché de consultas si las modificaciones no afectan las lecturas repetibles para otras transacciones. Desafortunadamente, InnoDB simplemente no hace eso. Aparentemente, tiene muchas consultas que se invalidan con bastante rapidez y probablemente no se reutilicen.
Para InnoDB en MySQL 4.0, la caché de consultas estaba deshabilitada para las transacciones. Para MySQL 4.1+, InnoDB juega al policía de tráfico cuando permite el acceso al caché de consultas por tabla.
Desde la perspectiva de su pregunta, diría que la justificación de eliminar la caché de consultas no es tanto la sobrecarga, sino cómo InnoDB lo maneja.
Para obtener más información sobre cómo InnoDB interactúa con el caché de consultas, lea las páginas 213-215 del libro "High Performance MySQL (Segunda edición)" .
Si todos o la mayoría de sus datos son MyISAM, podría seguir con su idea original de usar SQL_NO_CACHE.
Si tiene una combinación de InnoDB y MyISAM, tendrá que encontrar el equilibrio adecuado para su aplicación en función de cuán altas sean las pérdidas de caché. De hecho, las páginas 209-210 del mismo libro señalan las razones de las fallas de caché:
- La consulta no se puede almacenar en caché, ya sea porque contiene una construcción no determinista (como CURRENT_DATE) o porque su conjunto de resultados es demasiado grande para almacenar. Ambos tipos de consultas no almacenables en caché incrementan la variable de estado Qcache_not_cached.
- El servidor nunca antes había visto la consulta, por lo que nunca tuvo la oportunidad de almacenar en caché su resultado.
- El resultado de la consulta fue previamente almacenado en caché, pero el servidor lo eliminó. Esto puede suceder porque no había suficiente memoria para mantenerlo, porque alguien le indicó al servidor que lo eliminara o porque se invalidó
y las causas raíz de errores de caché altos con pocas consultas que no se pueden almacenar en caché pueden ser:
- El caché de consultas aún no está caliente. Es decir, el servidor no ha tenido la oportunidad de llenar el caché con conjuntos de resultados.
- El servidor está viendo consultas que no ha visto antes. Si no tiene muchas consultas repetidas, esto puede suceder incluso después de que el caché se haya calentado.
- Hay muchas invalidaciones de caché.
ACTUALIZACIÓN 2012-09-06 10:10 EDT
Buscando su última información actualizada, la ha query_cache_limitconfigurado en 1048576 (1M). Esto limita cualquier conjunto de resultados a 1M. Si recupera algo más grande, simplemente no se almacenará en caché. Si bien se ha query_cache_sizeconfigurado en 104857600 (100M), esto solo permite 100 resultados en caché establecidos en un mundo perfecto. Si realiza cientos de consultas, la fragmentación se producirá con bastante rapidez. También tiene 4096 (4K) como el conjunto de resultados de tamaño mínimo. Desafortunadamente, mysql no tiene un mecanismo interno para desfragmentar el caché de consultas.
Si debe tener el caché de consultas y tiene tanta RAM, puede ejecutar lo siguiente:
SET GLOBAL query_cache_size = 0;
SELECT SLEEP(60);
SET GLOBAL query_cache_size = 1024 * 1024 * 1024;
para purgar el caché de consultas. Pierde todos los resultados almacenados en caché, así que ejecute estas líneas durante las horas de menor actividad.
También asignaría lo siguiente:
- query_cache_size = 1G
- query_cache_limit = 8M
Eso deja 23G de RAM. Yo plantearía lo siguiente:
- innodb_buffer_pool_size = 12G
- key_buffer_size = 4G
Eso deja 7G. Esto debería ser adecuado para OS y conexiones DB.
Tenga en cuenta que el búfer clave almacena en caché solo las páginas de índice MyISAM, mientras que el InnoDB Buffer Pool almacena en caché datos e índices.
Una recomendación más: actualice a MySQL 5.5 para que pueda configurar InnoDB para múltiples CPU y múltiples hilos para E / S de lectura / escritura.
Vea mis publicaciones anteriores sobre el uso de MySQL 5.5 junto con el acceso a múltiples CPU para InnoDB
ACTUALIZACIÓN 2012-09-06 14:56 EDT
Mi método para borrar el caché de consultas es bastante extremo porque almacena datos en caché y forma un segmento de RAM completamente diferente. Como señaló en su comentario, FLUSH QUERY CACHE(como sugirió) o incluso RESET QUERY CACHEsería mejor. Para aclarar, cuando dije "sin mecanismo interno", quise decir exactamente eso. La desfragmentación es necesaria y debe hacerse manualmente. Tendría que ser crontab'd .
Si hace DML (INSERTs, UPDATEs, DELETEs) en InnoDB con más frecuencia que en MyISAM, diría que elimine la caché de consultas por completo, lo que dije al principio.