Hace más de tres años, publiqué una corrección en Plan Explorer con respecto a las malas estimaciones de cardinalidad que producía Showplan XML de SQL Server, en el caso de búsquedas de clave/RID con un predicado de filtro en SQL Server 2008 y superior. Pensé que sería interesante mirar hacia atrás y profundizar un poco más en uno de estos planes y las iteraciones que realizamos para asegurarnos de que mostráramos las métricas correctas, independientemente de lo que muestre Management Studio. Una vez más, este trabajo fue realizado en gran parte por Brooke Philpott (@MacroMullet) y Greg Gonzalez (@SQLsensei) y con la gran contribución de Paul White (@SQL_Kiwi).
Esto es bastante similar a la consulta que presenté en mi publicación anterior, que provino de Paul (y cuya reproducción precisaría algo de trabajo en las versiones modernas de AdventureWorks, donde, como mínimo, las fechas de transacción han cambiado):
SELECT
th.ProductID,
p.Name,
th.TransactionID,
th.TransactionDate
FROM Production.Product AS p
JOIN Production.TransactionHistory AS th ON
th.ProductID = p.ProductID
WHERE
p.ProductID IN (1, 2)
AND th.TransactionDate BETWEEN '20070901' AND '20071231'; El plan de Management Studio parecía bastante correcto:
Sin embargo, si mira más de cerca, parece que ShowPlan ha llevado el número estimado de ejecuciones de la búsqueda de clave directamente al número estimado de filas para el intercambio final:
A primera vista, el diagrama del plan gráfico en Plan Explorer se parece bastante al plan que produce SSMS:
Ahora, en el proceso de desarrollo de Plan Explorer, hemos descubierto varios casos en los que ShowPlan no tiene las matemáticas correctas. El ejemplo más obvio son los porcentajes que suman más del 100%; hacemos esto bien en los casos en que SSMS está ridículamente desactivado (hoy veo esto con menos frecuencia que antes, pero aún sucede).
Otro caso es donde, a partir de SQL Server 2008, SSMS comenzó a colocar el total de filas estimadas en lugar de las filas por ejecución junto con las búsquedas, pero solo en los casos en los que se inserta un predicado en la búsqueda (como el caso de este error informado por Paul, y esta observación más reciente de Joey D'Antoni). En versiones anteriores de SQL Server (y con funciones y spools), normalmente mostrábamos los recuentos de filas estimados que surgían de una búsqueda al multiplicar las filas estimadas por ejecución (generalmente 1) por la cantidad estimada de filas según SSMS. Pero con este cambio, estaríamos contando en exceso, ya que el operador ahora ya está haciendo esos cálculos. Por lo tanto, en versiones anteriores de Plan Explorer, en comparación con 2008+, vería estos detalles en la información sobre herramientas, las líneas de conexión o en las distintas cuadrículas:
(¿De dónde viene 1721? 67,5 ejecuciones estimadas x 25,4927 filas estimadas).
En 2012, solucionamos parte de este problema al dejar de realizar esta operación matemática y confiar únicamente en los recuentos de filas estimados que surgieron de la búsqueda de claves. Esto era casi correcto, pero aún confiábamos en el recuento de filas estimado que ShowPlan nos proporcionaba para el intercambio final:
También abordamos este problema rápidamente, en la versión 7.2.42.0 (lanzada en Halloween de 2012), y ahora sentimos que estamos brindando información que es mucho más precisa que Management Studio (aunque estaremos atentos a este error de Paul) :
Esto claramente sucedió hace mucho tiempo, pero aún así pensé que sería interesante compartirlo. Seguimos realizando mejoras en Plan Explorer para brindarle la información más precisa posible, y compartiré algunas más de estas pepitas en las próximas publicaciones.
