Es fácil comenzar a jugar con los engranajes de la optimización de consultas SQL. Abre SQL Server Management Studio (SSMS), supervisa el tiempo de espera, revisa el plan de ejecución, recopila información de objetos y comienza a optimizar SQL hasta que esté ejecutando una máquina perfectamente ajustada.
Si eres lo suficientemente bueno en eso, obtienes una victoria rápida y vuelves a tu caos programado regularmente. Pero si ajustas lo incorrecto, o ajustas lo correcto en la dirección incorrecta, bueno, ahí se fue tu miércoles.
¿Optimización de consultas SQL? ¿Qué te hace pensar que lo necesitas?
La mayoría de las veces, es un aumento en los tickets de problemas o las quejas de los usuarios. “¿Por qué el sistema es tan lento?” sus usuarios se quejan. "Nos está tomando una eternidad ejecutar nuestros informes habituales esta semana".
Esa es una descripción bastante vaga, por supuesto. Sería bueno si pudieran decirle:“Las cosas son lentas porque tiene una conversión implícita en la línea 62 de CurrentOrderQuery5.sql. La columna es varchar y estás pasando un número entero”. Pero no es probable que sus usuarios puedan ver ese nivel de detalle.
Al menos los tickets de problemas y las llamadas telefónicas constituyen una métrica activa:fácil de detectar, fácil de medir. Cuando comiencen a aparecer, puede estar razonablemente seguro de que es hora de ajustar SQL.
Pero hay otras métricas pasivas que hacen que la necesidad sea menos clara. Cosas como la caída de las ventas, que podría deberse a una serie de factores. ¿Es porque las consultas dolorosamente lentas en su tienda en línea están haciendo que sus clientes abandonen sus carritos de compras? ¿Es porque la economía está en mal estado?
O podría ser cosas como un rendimiento lento de SQL Server. ¿Es porque una consulta mal escrita está enviando lecturas lógicas por las nubes? ¿Es porque el servidor tiene pocos recursos físicos como memoria y almacenamiento?
En ambos escenarios, la optimización de consultas SQL puede ayudar con la primera opción, pero no con la segunda.
¿Por qué aplicar la solución correcta al problema equivocado?
Antes de seguir el camino de la optimización, asegúrese de que el ajuste sea la solución correcta para el problema correcto.
Ajustar SQL es un proceso técnico, pero cada paso técnico tiene sus raíces en un buen sentido comercial. Podría pasar días tratando de acortar el tiempo de ejecución en unos pocos milisegundos o reducir la cantidad de lecturas lógicas en un cinco por ciento, pero ¿vale la pena la reducción? Es cierto que es importante cumplir con los requisitos de los usuarios, pero todos los esfuerzos llegan al punto de rendimientos decrecientes con el tiempo.
Considere estos problemas de rendimiento de consultas SQL y el contexto comercial que los rodea:
- Rendimiento aceptable — Una consulta tarda 10 minutos en ejecutarse y el usuario desea que se ejecute en un minuto; eso parece una disparidad razonable y un objetivo alcanzable para la optimización. Sin embargo, si la consulta tarda toda la noche y el usuario cree que debería ejecutarse en un minuto, entonces puede ser más que un problema de ajuste. Por un lado, es posible que deba educar al usuario sobre la cantidad de trabajo que realmente está realizando la consulta. Por otro lado, puede ser un problema con la forma en que se diseñó la base de datos o la forma en que se escribió la aplicación del cliente.
- Utilidad — Suponga que es responsable de administrar la base de datos financiera en una empresa manufacturera. Al final de cada mes, los usuarios se quejan del bajo rendimiento. Rastrea el problema hasta una serie de informes de fin de mes realizados por Contabilidad que toman horas cada uno y van directamente a un archivador sin que nadie los examine. En lugar de ajustar, explica el problema a los gerentes comerciales y obtiene permiso para eliminar los informes.
- Cambio de horario — O suponga que esos mismos informes son importantes para la gobernanza pero no urgentes para el negocio. Si se ejecutan una vez por semana o por mes, se pueden programar para las horas de menor actividad almacenando previamente en caché el conjunto de datos y enviando los resultados a un archivo. Eso elimina el cuello de botella en los otros usuarios comerciales y libera al usuario de Contabilidad de tener que esperar los informes.
Cuando tiene en cuenta el contexto comercial en su decisión de optimizar, puede establecer prioridades y ganar tiempo.
Cuando optimice consultas SQL, intente diagramar SQL
SSMS y las herramientas integradas en SQL Server ofrecen la mayor parte de lo que necesita para una optimización eficaz de consultas SQL. Combine las herramientas con un enfoque metódico en torno a los siguientes pasos, como se describe en el libro electrónico "La guía fundamental para la optimización de consultas SQL":
- Supervisar el tiempo de espera
- Revisar el Plan de Ejecución
- Recopilar información del objeto
- Encuentra la mesa de conducción
- Identificar inhibidores de rendimiento
En el paso 4, su objetivo es impulsar la consulta con la tabla que devuelve la menor cantidad de datos. Cuando estudia uniones y predicados, y filtra antes en la consulta en lugar de después, reduce el número de lecturas lógicas. Ese es un gran paso en la optimización de consultas SQL.
La diagramación SQL es una técnica gráfica para mapear la cantidad de datos en las tablas y encontrar qué filtro devolverá la menor cantidad de registros. Primero, determine qué tablas contienen la información detallada y qué tablas son las tablas maestras o de consulta. Considere el ejemplo simple de esta consulta contra una base de datos de registro universitario:
La tabla de detalle es el registro. Tiene dos tablas de búsqueda, estudiante y clase. Para diagramar estas tablas, dibuje un árbol invertido que conecte la tabla de detalles (en la parte superior) con flechas (o enlaces) a las tablas de búsqueda, así:
Ahora, calcule el número relativo de registros necesarios para los criterios de combinación (es decir, la proporción promedio de filas relacionadas entre la tabla de detalles y las tablas de búsqueda). Escribe los números en cada extremo de la flecha. En este ejemplo, por cada alumno hay unos 5 registros en la tabla de registro, y por cada clase hay unos 30 registros en el registro. Eso significa que nunca debería ser necesario UNIRSE a más de 150 (5×30) registros para obtener un resultado para un solo estudiante o una sola clase.
Ese ejercicio es útil si sus columnas de combinación no están indexadas o si no está seguro de que estén indexadas.
A continuación, mire los predicados de filtrado para encontrar con qué tabla realizar la consulta. Esta consulta tenía dos filtros:uno en registro cancelado ='N' y el otro en signup_date entre dos fechas. Para ver qué tan selectivo es el filtro, ejecute esta consulta al registrarse:
seleccione el recuento (1) del registro donde se canceló ='N'
Y r.signup_date ENTRE :beg_date Y :beg_date +1
Devuelve 4.344 registros de los 79.800 registros totales en el registro. Es decir, el 5,43 por ciento de los registros se leerán con ese filtro.
El otro filtro está en clase:
seleccione count(1) de la clase donde nombre ='INGLÉS 101'
Devuelve dos registros de 1000, o el 0,2 por ciento, lo que representa un filtro mucho más selectivo. Por lo tanto, la clase es la tabla de control y en la que debe enfocar primero su ajuste de SQL.
La voz del usuario
Si está seguro de que necesita ajustar SQL, "La guía fundamental para la optimización de consultas SQL" ofrece más información. Lo guía a través de cinco sugerencias de ajuste de rendimiento con consultas de copiar y pegar y estudios de casos, incluido el descrito anteriormente.
Probablemente encontrará que la herramienta de optimización de consultas SQL más importante es la voz del usuario. ¿Por qué? Porque esa voz te permite saber cuándo empezar a optimizar y te dice cuándo has optimizado lo suficiente. Puede garantizar que comiences a jugar con los engranajes cuando lo necesites y te detengas mientras todavía estás adelante.
