sql >> Base de Datos >  >> Database Tools >> SSMS

Malas estimaciones de cardinalidad provenientes de los planes de ejecución de SSMS

Tengo que agradecer a algunas personas por una actualización reciente de SQL Sentry Plan Explorer. Brooke Philpott (@Macromullet) y Greg Gonzalez (blog | @SQLsensei), por supuesto, por I+D y por profundizar en el código y clasificarlo. Pero también a Paul White (blog | @SQL_kiwi) por ser persistente en ayudarnos a validar las correcciones.

El problema que descubrió Paul es que SQL Server 2008+ confunde las estimaciones de cardinalidad en ciertas consultas cuando se trata de búsquedas de clave o RID. Dejaré la explicación más profunda para la publicación del blog de Paul y el error que presentó en Connect, pero para resumir, estábamos tomando estas estimaciones tergiversadas, creyéndolas y extrapolándolas para mostrarle "mejor" información. Lamentablemente, como explica Paul, nos engañaron.

Paul muestra la siguiente consulta en una copia de AdventureWorks 2005.

SELECT
    th.ProductID,
    th.TransactionID,
    th.TransactionDate
FROM Production.TransactionHistory AS th 
WHERE 
    th.ProductID = 1 
    AND th.TransactionDate BETWEEN '20030901' AND '20031231';

Management Studio genera el siguiente plan, tal como lo describió Paul:

En Plan Explorer, intentamos ser útiles al multiplicar el número estimado de filas (redondeado a 17) por el número de ejecuciones (45), y obtuvimos 765:

Para la mayoría de los operadores, este enfoque genera los datos correctos, pero debido a este error en SQL Server, no es correcto para las búsquedas de clave/RID. Nos ajustamos a eso y lanzamos la solución adecuada en 7.2.42.0 (¡descárgala ahora!). El plan gráfico ahora muestra correctamente los recuentos de filas correctos para ambos estimados:

Y real:

Repetiré la advertencia de Paul:Cuidado con las estimaciones de cardinalidad deficientes cuando se aplica un predicado como parte de una búsqueda.

Hubo algunos problemas más complejos causados ​​por estas estimaciones engañosas, que también hemos abordado. Escribiré en un blog sobre algunos de ellos en una publicación de seguimiento; para esta publicación, solo quería demostrar que resolvimos rápidamente el problema específico que Paul destacó en su publicación.