sql-server - not - sentencia between mysql

¿Qué hace que una sentencia de SQL sea sargable?

Question

Por definición (al menos por lo que he visto), sargable significa que una consulta es capaz de que el motor de consultas optimice el plan de ejecución que utiliza la consulta. He intentado buscar las respuestas, pero no parece haber mucho sobre el tema. Entonces la pregunta es, ¿qué hace o no hace que una consulta de SQL sea sargable? Cualquier documentación sería muy apreciada.

Para referencia: SARGable

Answer 1

En esta respuesta asumo que la base de datos tiene suficientes índices de cobertura. Hay suficientes preguntas sobre este tema .

Muchas veces, la capacidad de sargabilidad de una consulta está determinada por el punto de inflexión de los índices relacionados. El punto de inflexión define la diferencia entre buscar y escanear un índice al unir una tabla o conjunto de resultados en otra. Una búsqueda es, por supuesto, mucho más rápida que escanear una tabla completa, pero cuando tiene que buscar muchas filas, un escaneo podría tener más sentido.

Entonces, entre otras cosas, una declaración SQL es más fácil de cargar cuando el optimizador espera que el número de filas resultantes de una tabla sea menor que el punto de inflexión de un posible índice en la tabla siguiente.

Puedes encontrar un post detallado y un ejemplo here .

Answer 2

Lo más común que hará que una consulta no sea sargable es incluir un campo dentro de una función en la cláusula where:

SELECT ... FROM ...
WHERE Year(myDate) = 2008

El optimizador de SQL no puede usar un índice en myDate, incluso si existe uno. Literalmente tendrá que evaluar esta función para cada fila de la tabla. Mucho mejor de usar:

WHERE myDate >= ''01-01-2008'' AND myDate < ''01-01-2009''

Algunos otros ejemplos:

Bad: Select ... WHERE isNull(FullName,''Ed Jones'') = ''Ed Jones''
Fixed: Select ... WHERE ((FullName = ''Ed Jones'') OR (FullName IS NULL))

Bad: Select ... WHERE SUBSTRING(DealerName,4) = ''Ford''
Fixed: Select ... WHERE DealerName Like ''Ford%''

Bad: Select ... WHERE DateDiff(mm,OrderDate,GetDate()) >= 30
Fixed: Select ... WHERE OrderDate < DateAdd(mm,-30,GetDate()) 

Answer 3

Para que una operación se considere sargable, no es suficiente que solo pueda usar un índice existente. En el ejemplo anterior, la adición de una llamada de función contra una columna indexada en la cláusula where, probablemente aún aprovechará el índice definido. Se "escaneará" al igual que recuperará todos los valores de esa columna (índice) y luego eliminará los que no coincidan con el valor de filtro proporcionado. Todavía no es lo suficientemente eficiente para tablas con alto número de filas. Lo que realmente define la sargabilidad es la capacidad de consulta para atravesar el índice b-tree utilizando el método de búsqueda binario que se basa en la eliminación de medio conjunto para la matriz de elementos ordenados. En SQL, se mostraría en el plan de ejecución como una "búsqueda de índice".

Answer 4

No hagas esto

WHERE Field LIKE ''%blah%''

Eso causa una exploración de tabla / índice, porque el valor LIKE comienza con un carácter comodín.

No hagas esto

WHERE FUNCTION(Field) = ''BLAH''

Eso causa un escaneo de tabla / índice.

El servidor de la base de datos tendrá que evaluar FUNCTION () en cada fila de la tabla y luego compararla con ''BLAH''.

Si es posible, hacerlo a la inversa:

WHERE Field = INVERSE_FUNCTION(''BLAH'')

Esto ejecutará INVERSE_FUNCTION () contra el parámetro una vez y aún permitirá el uso del índice.