El rendimiento deficiente de la base de datos es una espina en el costado de cada DBA. Y no siempre es fácil aislar la causa raíz de los problemas de rendimiento, lo que solo aumenta el estrés.
Ajustar sus bases de datos de SQL Server es una excelente manera de resolver algunos de sus problemas de rendimiento, pero puede que no siempre sea obvio dónde debe comenzar el proceso de optimización. Si descarta el espacio en disco, la memoria y otros factores que afectan el rendimiento de la red y el hardware, y el rendimiento de SQL Server aún se está quedando atrás, es hora de profundizar en sus consultas.
Las consultas no optimizadas pueden causar innumerables problemas de rendimiento para sus sistemas. En el lado positivo, algunos errores de consulta comunes son responsables de la mayor parte de la degradación del rendimiento de la base de datos.
Si sus consultas sufren alguno de estos seis problemas, prepárese para un ajuste de rendimiento serio.
Consulta de problema n.º 1:Expresiones similares con comodines iniciales
Los comodines iniciales evitan que MySQL utilice índices, lo que obliga a realizar un análisis completo de la tabla incluso si ha indexado un campo dentro de la tabla. Escanear todas las filas de una tabla ralentiza significativamente la entrega de los resultados de su consulta, así que elimine el comodín inicial para mejorar la eficiencia.
Consulta de problema n.º 2:columnas no indexadas utilizadas en las cláusulas "Dónde" y "Agrupar por"
La indexación de columnas ayuda a devolver los resultados de las consultas más rápido porque elimina la necesidad de realizar exploraciones de tablas completas. La indexación también ayuda a ordenar los registros cuando se devuelven y garantiza que esos registros sean identificables de forma única, lo que es particularmente útil en tablas con más de 10 filas.
Para tener un poco de perspectiva, considere ejecutar una declaración de "explicación" en su análisis de consulta antes y después de la indexación. Esto le dará una idea de cuántas filas de escaneo acaba de guardar.
Consulta de problema n.º 3:declaraciones similares que usan el operador 'o' en lugar de una cláusula de unión
Ejecutar consultas usando el operador de comparación "o" en campos o columnas en una tabla puede ser útil, pero aplicar "o" con demasiada frecuencia en una cláusula "dónde" es otra vía rápida para un escaneo completo de la tabla.
Una cláusula de unión puede hacer que la consulta SQL se ejecute más rápido, especialmente si diferentes índices optimizan cada lado de la consulta. Esencialmente, el operador de unión toma los resultados de dos consultas indexadas rápidas y las fusiona en una sola.
Consulta de problema n.º 4:búsquedas con comodines
Si está atascado en una situación en la que necesita buscar con comodines pero no quiere sufrir el impacto del rendimiento, intente utilizar una búsqueda de texto completo de MySQL. Las búsquedas de texto completo son considerablemente más rápidas que las búsquedas con caracteres comodín, y obtiene el beneficio adicional de resultados más relevantes cuando busca en bases de datos enormes.
Consulta de problema n.º 5:esquema de base de datos no optimizado
Solo puede mejorar tanto el rendimiento de las consultas SQL si no optimiza también el esquema de su base de datos. Estos son algunos consejos para mejorar:
Normalizar tablas
La redundancia de datos perjudica el rendimiento, así que asegúrese de representar un hecho solo una vez en la base de datos. Por ejemplo, si hace referencia a un cliente en más de una tabla, use solo "nombre_cliente" una vez, luego use "ID_cliente" para las referencias posteriores.
Usar tipos de datos óptimos
Algunos puntos importantes para recordar cuando se trata de tipos de datos:
- Cuanto más corto, mejor al diseñar tablas. Por ejemplo, use el tipo de datos "TINYINT" para el campo "user_id" para una tabla de usuarios del sistema con menos de 100 usuarios.
- Use un tipo de datos "fecha_hora" si un campo espera un valor de fecha para que no tenga que convertir los registros al formato de fecha después del hecho.
- MySQL funciona mejor con valores enteros que con tipos de datos de texto, incluido varchar.
Evitar valores nulos
Los valores nulos en una columna pueden dañar los resultados de su consulta, por lo que es posible que deba asignar un valor predeterminado para los campos donde los registros no requieren un valor obligatorio.
No use demasiadas columnas
Las tablas anchas (más de 100 columnas) requieren una gran cantidad de CPU y recursos para procesar. A menos que sea absolutamente necesario incluir una tabla ancha, es mejor dividirla en tablas lógicas más pequeñas.
Optimizar uniones
Las sentencias SQL con demasiadas uniones (y uniones con demasiadas tablas) afectan negativamente al rendimiento. Busque no más de 12 uniones para cada consulta.
Consulta de problema n.º 6:Consultas de MySQL no almacenadas en caché
Los sitios web y las aplicaciones que realizan muchas consultas seleccionadas se beneficiarán del almacenamiento en caché de consultas MySQL. El almacenamiento en caché de consultas de MySQL acelera el rendimiento durante las operaciones de lectura porque almacena en caché la consulta de selección junto con el conjunto de datos resultante y obtiene de la memoria (no del disco) si la consulta se ejecuta más de una vez.
El ajuste del rendimiento es esencial para mantener una alta disponibilidad de sus bases de datos de SQL Server y garantizar que sus usuarios finales estén contentos. Pero desafortunadamente, no siempre es inmediatamente obvio dónde se necesita más ajuste. Si ha eliminado las fuentes obvias de red y hardware para los problemas de rendimiento, cambie su enfoque a sus consultas.
Si ha estado trabajando como administrador de bases de datos durante algún tiempo, es probable que haya encontrado una (o todas) de estas consultas problemáticas. Ahora que sabe lo que debe buscar, sea proactivo en su iniciativa de mejora del rendimiento y corrija estos puntos débiles comunes de las consultas para que pueda cosechar las recompensas de la optimización de consultas de SQL Server.
