¿Con qué cardinality SQL Server cambia a un análisis de índice (frente a buscar)

Question

Suponiendo que una tabla contiene información suficiente para garantizar una búsqueda de índice, ¿con qué cardinalidad SQL Server (o PostgreSQL) optará por un análisis de índice?

La razón por la que pregunto esto es que anteriormente publiqué una pregunta (link) en la que dos consultas se realizaron a la misma velocidad, pero una no intentó usar el índice en las columnas procesadas. Después de que SQL Server sugirió poner un que cubría el índice que incluía las columnas que se consultaban (sugirió esto para ambas consultas), comencé a buscar razones de por qué sería una sugerencia tan extraña.

Experimenté con hacer los índices que cubre y el compuesto, pero ambos se ejecutaron en el mismo tiempo (estamos hablando de 3 millones de filas).

Finalmente llegué a la conclusión de que era debido a la cardinalidad ultra alta de los datos. Cada fila es única. Estoy deduciendo que esto causó que el servidor SQL elija un análisis de índice. Sin embargo, la consulta indicó "WHERE Col1>? AND Col2 <?", Por lo que esto es un poco confuso.

Mis preguntas son:

1. En lo que se cardinalidad de un RDBMS siempre optan por una exploración de índice?
2. ¿Alguien puede explicar por qué SQL Server no usaría el índice cuando la instrucción WHERE indicaría que esto tendría sentido?

He adjuntado el plan de ejecución.

Answer 1

En términos de SQL Server, este ha sido referido como el punto de inflexión, del cual la publicación de blog de Kimberley es una buena lectura. http://www.sqlskills.com/BLOGS/KIMBERLY/category/The-Tipping-Point.aspx

El punto de inflexión es una directriz del 25% -33% del número total de páginas dentro de la tabla, expresadas como filas, p. 10k páginas de datos darían un punto de inflexión de 2500-3333 filas. Según las directrices, esto es bastante bueno, y tan bueno como sea posible, recuerde que el motor del plan de consulta es una caja negra, y aunque le dará un plan de consulta, solo dice lo que decidió, no por qué.

Sin embargo, en términos de inclinar un índice de cobertura, eso no es realmente fácil, incluso con el 100% de los datos seleccionados, un índice de cobertura seguirá buscando sobre el escaneo en la mayoría de los casos.

Eso tiene sentido, si se tiene en cuenta que el optimizador de costos no asigna ningún costo real a la jerarquía de páginas de índice, solo cuesta el acceso a las páginas de hoja del índice. En ese punto, escanear o buscar el 100% de un índice de cobertura tiene el mismo costo.

Encontré por mi propia experimentación (http://sqlfascination.com/2009/11/07/can-a-covering-nc-index-be-tipped) usando una cláusula between que causaba que escaneara, pero otras cláusulas no lo harían, por lo que pude ver, fue puramente por la ruta a través del motor de búsqueda.

Answer 2

En PostgreSQL, generalmente esta no es una buena pregunta porque la selección del plan real es más complicada. Depende del tamaño de la tabla, la configuración de la memoria y otras partes de la consulta. Por lo general, obtendrá un análisis de índice simple solo si está seleccionando muy pocas filas. Por encima de eso, obtendrás un escaneo de índice de mapa de bits para decir 40% de selectividad en experimentos simples.