SqlServer, plan de consulta y optimización (Tuning) (1)

SqlServer, plan de consulta y optimización (Tuning) (1)

De mi parte, siempre di la derecha al plan de consulta que el motor escogía, si el rendimiento no es el esperado sera porque diseñe mal la base o porque me faltan indices o directamente porque el software esta trabajando de manera incorrecta. Tengo desarrollos completos, algunos de tiempo real con bastante exigencia al motor donde la cantidad de planes de consulta forzados en todo los módulos del software es 0.

Hace mucho años trabajando para una compañía bastante grande observaba horrorizado como se había instalado la cultura de crear la consulta e indicar porque indice ir.
Meses después tuve mi revancha cuando nos mandaron a todos a hacer un curso de tuning de sql, y si no fue lo primero, lo segundo que dijo el instructor fue “No fuercen el plan de consulta, es muy probable que no tengan el conocimiento y la cantidad de información necesaria para hacerlo”
Los mismo dice microsoft en su msdn, traducción mediante “Típicamente sqlserver encuentra el mejor plan posible, no lo cambie salvo que sea un experto programador o experto administrador de base de datos”.

Probablemente todos nos sentimos expertos programadores, sea así o no, con eso no alcanza. Ademas de la experiencia se necesita conocimiento del modelo, de los indices y de la distribución y naturaleza de la información, en la mayoría de los casos conocer todo esto es poco probable y casualmente el sqlServer (Correctamente configurado) en sus estadísticas tiene esta información con un nivel de confiabilidad superior al 80%.

Entonces si no hay posibilidades de mejora y el motor es perfecto ¿Por que existen los hints?
Bueno de hecho el motor sí se equivoca, poco, pero se equivoca con especial énfasis en las siguientes situaciones:

1. Datos correlacionados
2. Poda por heuristica
3. Bug optimizador
4. Estadísticas no actualizadas

¿Entonces modifico o no el plan de consulta?

Entiendo que modificar el plan de consulta es la solución mas tentadora a un problema de rendimiento, generalmente parece ser también la solución menos probable hasta puede ofrecer mejoras marginales en muchos casos.
En posteriores entradas voy a intentar desgranar situaciones donde malos diseños, bugs del optimizador, datos correlacionados, podas o malas estadísticas puedan hacer que el sql se equivoque groseramente.