Los expertos saben cómo escribir consultas de rendimiento eficiente. Aunque la experiencia madura la sabiduría, hay ciertas cosas que uno debe entender al menos para empezar. Por ejemplo, debe comprender las consideraciones clave del diseño de consultas; cómo funciona una consulta internamente, dónde falla, patrones de optimización, etc. En este artículo, proporcionaré algunos puntos de optimización para reflexionar al diseñar una consulta en MySQL.
¿Por qué algunas consultas son lentas?
Un problema común con las consultas SQL es que se recuperan más datos de los que realmente se necesitan. Por supuesto, hay consultas que filtran una gran cantidad de datos y no podemos hacer mucho al respecto, pero no son comunes. En la mayoría de los casos, es un mal diseño de consulta lo que conduce a un rendimiento deficiente de la consulta. Después de cada diseño de consulta, debe reflexionar sobre un par de aspectos, como lo que podría suceder después de que se activa la consulta:
- ¿La consulta SQL accederá a demasiadas columnas o filas?
- ¿El servidor MySQL analizará demasiadas filas para obtener el resultado deseado?
Hay consultas que hacen que el servidor MySQL analice demasiados datos, pero los arroja a medida que los tamiza. Este es un trabajo adicional para el servidor en términos de muchos aspectos, como la sobrecarga de la red, el consumo excesivo de memoria o el uso excesivo de recursos de CPU en el servidor. La consecuencia es un rendimiento lento.
Hay situaciones en las que es posible que no pueda ayudar mucho durante su diseño, pero hay una situación en la que si tiene cuidado y estima las consecuencias y la introspección, entonces una mala consulta puede al menos hacerse buena, si no mejor.
Errores típicos y sus soluciones
Hay bastantes errores comunes que se cometen a menudo al escribir una consulta. Éstos son algunos de ellos. Puede encontrar algunos pensamientos más en la misma línea. Estos son los motivos del rendimiento lento de las consultas con posibles soluciones.
Demasiadas filas
A menudo se comete el error de escribir una consulta que recupera datos y asumir que MySQL proporcionará resultados a pedido mientras se pasa por alto la cantidad de procesamiento requerido para devolver el conjunto de resultados completo. Supongamos que se activa una declaración SELECT para obtener 100 detalles de productos para un sitio de comercio electrónico cuando solo 10 de ellos deben mostrarse primero. Podría pensar que MySQL obtiene solo 10 filas y deja de ejecutar la consulta. Pero no. Lo que hace MySQL es generar el conjunto de resultados completo y alimentar al cliente. La biblioteca del cliente recibe el conjunto completo y descarta la mayor parte y retiene solo 10 de los que busca. Esto claramente desperdicia muchos recursos.
Sin embargo, en tal situación, puede proporcionar una solución utilizando la cláusula LIMIT con la consulta.
SELECT col1, col2,... FROM table_name LIMIT [offset,] count;
La cláusula LIMIT acepta uno o dos parámetros. El primero especifica el desplazamiento y el segundo especifica el recuento. Si solo se especifica un parámetro, indica el número de filas desde el principio del conjunto de resultados.
Por ejemplo, para seleccionar 10 filas de la tabla, puede escribir:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10;
Y para seleccionar las próximas 10 filas, a partir de 11 registros, puede escribir:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10, 10;
Demasiadas columnas
Mire siempre la consulta:SELECT * con recelo. Esta consulta devuelve todas las columnas y probablemente solo necesite algunas de ellas. La mayor desventaja de recuperar todas las columnas es que impide la optimización al dificultar el uso de índices, exige demasiados recursos de E/S, memoria y CPU del servidor.
Comprenda que una consulta tan universal que recupera todas las columnas puede ser un desperdicio. Algunos dicen que son útiles porque le permite al desarrollador usar el mismo fragmento de código en más de un lugar. Eso está bien si el costo involucrado es limitado dentro de la consideración. En algún momento, el almacenamiento en caché de los datos recuperados ayuda en este contexto. Pero tenga cuidado, sin embargo, aprovechar el rendimiento es un trabajo elegante y tal lujo puede no tener lugar para el rendimiento.
La regla general es evitar este tipo de consultas universales o mantener un número de columnas al mínimo posible.
Demasiado análisis de datos
Las consultas devuelven el resultado deseado que está bien, pero a veces estas consultas se escriben de tal manera que, mientras se procesan, es necesario examinar demasiados datos antes de generar resultados. Por lo tanto, en MySQL debes medir según las siguientes métricas de costos:
- Tiempo de ejecución
- Filas examinadas
- Columnas examinadas
Puede obtener una estimación aproximada del costo de la consulta a partir de estas métricas. Esto refleja la cantidad de acceso a datos por parte de MySQL internamente para procesar la consulta y qué tan rápido se ejecuta la consulta. Dado que estas métricas se registran en el registro de consultas lentas, es una buena idea investigar y encontrar consultas que analicen demasiados datos para devolver el resultado. La base de datos MySQL registra todas las consultas que exceden una determinada cantidad de tiempo de ejecución en el registro de consultas lentas. Este es un lugar ideal para buscar consultas lentas y averiguar con qué frecuencia son lentas.
Un registro de consultas lento normalmente se encuentra en /var/log/mysql/mysql-slow.log
Tenga en cuenta que es posible que tenga que configurar y habilitar el registro de consultas lentas en mysqld.cnf archivo de configuración de la siguiente manera.
#slow_query_log = 1 #slow_query_log_file = /var/log/mysql/mysql-slow.log #long_query_time = 2
Antes de MySQL 5 y con él, existían serias limitaciones, especialmente la falta de soporte para el registro detallado. El único respiro fue el uso de parches que permitieron el registro. Sin embargo, la función ha sido parte de MySQL 5.1 y servidores posteriores como parte de su función principal.
Las consultas que tardan demasiado tiempo en ejecutarse no significan necesariamente que sean malas consultas. El registro de consultas lentas simplemente brinda la oportunidad de examinar el rendimiento de las consultas y mejorarlo tanto como sea posible.
Reestructuración de consultas
Como tiene la oportunidad de reestructurar consultas problemáticas, su objetivo principal debe ser encontrar una solución alternativa para lograr el efecto que deseamos. Puede transformar la consulta en su forma equivalente teniendo en cuenta el efecto interno en el servidor MySQL durante el procesamiento.
Una decisión en el diseño de consultas es si debemos favorecer una consulta compleja en lugar de varias simples o viceversa. El enfoque convencional del diseño de bases de datos es hacer tantos trabajos como sea posible con menos consultas. La razón es que una consulta grande/compleja es más rentable en términos de establecer una conexión con la base de datos. La ventaja de la reducción de costos a favor de la consulta compleja es el uso de la red, el procesamiento/optimización de consultas y la utilización de recursos. Pero este enfoque tradicional no encaja bien con MySQL. MySQL está diseñado para manejar la conexión y desconexión de la base de datos rápidamente. Por lo tanto, establecer la conexión, disparar muchas consultas más simples y cerrar la conexión parece más eficiente. La recuperación de datos a través de más de una consulta simple en lugar de una consulta grande y compleja es más eficaz. Tenga en cuenta que es posible que la misma idea no se aplique con otras bases de datos.
Conclusión
Estos son algunos consejos rápidos para la optimización de consultas. Comprenda que, conociendo las sintaxis de SQL, poder crear una consulta que recupere el resultado deseado no es suficiente si uno apunta al rendimiento de la consulta. Comprender lo que sucede debajo de las consultas aparentemente simples es vital para escribir una que no solo recupere lo que se desea, sino que imbuya el arte de la optimización desde donde todo comienza. Lo que sucede detrás de escena del procesamiento de consultas brinda una pista importante para comprender el rendimiento de las consultas y este conocimiento es imprescindible antes de incursionar en el ámbito de la optimización de consultas.
