Limitaciones del optimizador con índices filtrados

Lo extraño es que el optimizador debe haberse dado cuenta de que la combinación rechaza NULLs para elegir el índice filtrado para la tabla B busque, pero no pensó en filtrar NULLs de la tabla A primero, o mejor aún, simplemente escanear el NULLs -índice filtrado libre en la tabla A. Quizás se pregunte si esta es una decisión basada en costos, ¿quizás las estadísticas no son muy buenas? ¿Quizás deberíamos forzar el uso del índice filtrado con una pista? Indicar el índice filtrado en la tabla A solo da como resultado el mismo plan con los roles invertidos:escanear la tabla B y buscar en la tabla A. Forzar el índice filtrado para ambas tablas produce error 8622 :el procesador de consultas no pudo producir un plan de consulta.

Agregar un predicado NOT NULL

Sospechar que la causa tiene algo que ver con el NULLs implícito -rechazo del predicado de unión, agregamos un NOT NULL explícito predicado al ON cláusula (o el WHERE cláusula si lo prefiere, se trata de lo mismo aquí):

SELECT
    ta.data,
    tb.data
FROM dbo.TableA AS ta
JOIN dbo.TableB AS tb
    ON ta.data = tb.data
    AND ta.data IS NOT NULL;

Añadimos el NOT NULL verifique la columna de la tabla A porque el plan original escaneó el índice agrupado de esa tabla en lugar de usar nuestro índice filtrado (la búsqueda en la tabla B estuvo bien; sí usó el índice filtrado). La nueva consulta es semánticamente exactamente igual a la anterior, pero el plan de ejecución es diferente:

Ahora tenemos el escaneo esperado del índice filtrado en la tabla A, que produce 2,000 no NULLs filas para impulsar las búsquedas de bucle anidado en la tabla B. Ambas tablas están utilizando nuestros índices filtrados aparentemente de manera óptima ahora:el nuevo plan cuesta solo 0.362835 unidades (por debajo de 7.7768). Sin embargo, podemos hacerlo mejor.

Agregar dos predicados NOT NULL

El redundante NOT NULL el predicado de la tabla A hizo maravillas; ¿Qué sucede si también agregamos uno para la tabla B?

SELECT
    ta.data,
    tb.data
FROM dbo.TableA AS ta
JOIN dbo.TableB AS tb
    ON ta.data = tb.data
    AND ta.data IS NOT NULL 
    AND tb.data IS NOT NULL;

Esta consulta sigue siendo lógicamente la misma que los dos esfuerzos anteriores, pero el plan de ejecución es diferente nuevamente:

Este plan crea una tabla hash para las 2000 filas de la tabla A, luego busca coincidencias usando las 2000 filas de la tabla B. El número estimado de filas devueltas es mucho mejor que el plan anterior (¿observó la estimación de 7619 allí?) y el costo de ejecución estimado ha vuelto a caer, de 0,362835 a 0,0772056 .

Podría intentar forzar una unión hash utilizando una pista en el original o NOT NULL único consultas, pero no obtendrá el plan de bajo costo que se muestra arriba. El optimizador simplemente no tiene la capacidad de razonar completamente sobre el NULLs -rechazar el comportamiento de la combinación tal como se aplica a nuestros índices filtrados sin ambos predicados redundantes.

Puedes sorprenderte por esto, incluso si es solo la idea de que un predicado redundante no fue suficiente (seguramente si ta.data es NOT NULL y ta.data = tb.data , se deduce que tb.data es también NOT NULL , ¿verdad?)

Todavía no es perfecto

Es un poco sorprendente ver un hash unirse allí. Si está familiarizado con las principales diferencias entre los tres operadores de combinación física, probablemente sepa que la combinación hash es una de las principales candidatas donde:

1. La entrada preordenada no está disponible
2. La entrada de compilación hash es más pequeña que la entrada de la sonda
3. La entrada de la sonda es bastante grande

Ninguna de estas cosas es cierta aquí. Nuestra expectativa sería que el mejor plan para esta consulta y conjunto de datos sería una combinación de combinación, explotando la entrada ordenada disponible de nuestros dos índices filtrados. Podemos intentar insinuar una combinación de fusión, conservando los dos ON adicionales predicados de la cláusula:

SELECT 
    ta.data,
    tb.data
FROM dbo.TableA AS ta
JOIN dbo.TableB AS tb
    ON ta.data = tb.data
    AND ta.data IS NOT NULL 
    AND tb.data IS NOT NULL
OPTION (MERGE JOIN);

La forma del plano es como esperábamos:

Un escaneo ordenado de ambos índices filtrados, excelentes estimaciones de cardinalidad, fantástico. Solo un pequeño problema:este plan de ejecución es mucho peor; el coste estimado ha saltado de 0,0772056 a 0,741527 . El motivo del salto en el costo estimado se revela al verificar las propiedades del operador de combinación de fusión:

Esta es una combinación costosa de muchos a muchos, donde el motor de ejecución debe realizar un seguimiento de los duplicados de la entrada externa en una mesa de trabajo y rebobinar según sea necesario. ¿Duplicados? ¡Estamos escaneando un índice único! Resulta que el optimizador no sabe que un índice único filtrado produce valores únicos (conectar artículo aquí). De hecho, se trata de una unión uno a uno, pero el optimizador cuesta como si fuera muchos a muchos, lo que explica por qué prefiere el plan de unión hash.

Una estrategia alternativa

Parece que seguimos enfrentándonos a las limitaciones del optimizador cuando usamos índices filtrados aquí (a pesar de que es un caso de uso destacado en Books Online). ¿Qué sucede si intentamos usar vistas en su lugar?

Uso de vistas

Las siguientes dos vistas solo filtran las tablas base para mostrar las filas donde la columna de datos es NOT NULL :

CREATE VIEW dbo.VA
WITH SCHEMABINDING AS
SELECT
    pk,
    data,
    padding
FROM dbo.TableA
WHERE data IS NOT NULL;
GO
CREATE VIEW dbo.VB
WITH SCHEMABINDING AS
SELECT
    pk,
    data,
    padding
FROM dbo.TableB
WHERE data IS NOT NULL;

SELECT 
    v.data,
    v2.data
FROM dbo.VA AS v
JOIN dbo.VB AS v2
    ON v.data = v2.data;

CREATE UNIQUE CLUSTERED INDEX cuq ON dbo.VA (pk);
CREATE UNIQUE CLUSTERED INDEX cuq ON dbo.VB (pk);

CREATE UNIQUE NONCLUSTERED INDEX ix ON dbo.VA (data);
CREATE UNIQUE NONCLUSTERED INDEX ix ON dbo.VB (data);

SELECT 
    v.data,
    v2.data
FROM dbo.VA AS v WITH (NOEXPAND)
JOIN dbo.VB AS v2 WITH (NOEXPAND)
    ON v.data = v2.data;