Por definición (al menos por lo que he visto) sargable significa que una consulta es capaz de tener el motor de consulta optimizar el plan de ejecución que utiliza la consulta. Intenté buscar las respuestas, pero parece que no hay mucho sobre el tema. Entonces, la pregunta es, ¿qué hace o no una consulta SQL sargable? Cualquier documentación sería muy apreciada.¿Qué hace que una declaración SQL sea sargable?
Como referencia: Sargable
Lo más común que hará una consulta no 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 utilizar un índice en myDate, incluso si existe uno. Literalmente tendrá que evaluar esta función para cada fila de la tabla. Mucho mejor utilizar:
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())
¿Incluirá una función dentro de 'GROUP BY' que una consulta se vuelva no sargable? –
@MikeBantegui El simple hecho de incluir un campo en un GROUP BY no necesariamente lo hará no sargeable, no. Los índices correctos definitivamente ayudarán a una consulta GROUP BY. – BradC
* Algunos * motores de base de datos (Oracle, PostgreSQL) admiten índices en expresiones, ¿no sabe? – Craig
No haga esto:
WHERE Field LIKE '%blah%'
que causa un recorrido de tabla/índice, ya que el valor COMO comienza con un carácter comodín.
No haga esto:
WHERE FUNCTION(Field) = 'BLAH'
que causa un recorrido de tabla/índice.
El servidor de base de datos tendrá que evaluar la función() en contra de todas las filas de la tabla y luego compararlo con 'bla'.
Si es posible, lo hacen a la inversa:
WHERE Field = INVERSE_FUNCTION('BLAH')
Esto ejecutará INVERSE_FUNCTION() con el parámetro de una vez y todavía permite el uso del índice.
Su sugerencia de voltear la función realmente solo funcionaría cuando la función recorra los datos de ida y vuelta (lo que significa que f (f (n)) = n). –
Es cierto. Consideré agregar INVERSE_FUNCTION pero no quería ser confuso. Lo cambiaré. – beach
En esta respuesta Asumo la base de datos tiene suficientes índices de cobertura. Hay suficientes preguntas sobre this topic.
Muchas de las veces el sargability de una consulta es determinado por el punto de inflexión de los índices relacionados. El punto de inflexión define la diferencia entre buscar y escanear un índice mientras se une una tabla o conjunto de resultados a otra. Una búsqueda es, por supuesto, mucho más rápida que escanear una tabla completa, pero cuando hay que buscar muchas filas, un escaneo podría tener más sentido.
Por lo tanto, entre otras cosas, una declaración de SQL es más sargable 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 siguiente tabla.
Usted puede encontrar una entrada detallada y el ejemplo here.
Para que una operación se considera sargable, no es suficiente para que sólo ser capaz de utilizar un índice existente.En el ejemplo anterior, agregar una llamada a función contra una columna indexada en la cláusula where, aún así es probable que tome alguna ventaja del índice definido. Se "escaneará", también conocido como recuperar todos los valores de esa columna (índice) y luego eliminar los que no coinciden con el valor del filtro proporcionado. Todavía no es lo suficientemente eficiente para tablas con un alto número de filas. Lo que realmente define la sargabilidad es la capacidad de consulta para recorrer el índice del árbol b utilizando el método de búsqueda binario que se basa en la eliminación a medias para la matriz de elementos ordenados. En SQL, se mostraría en el plan de ejecución como una "búsqueda de índice".
+1 para "sargable". Esa es mi palabra del día para hoy. :-p – BFree
SARG = Search ARGument. Lo gracioso es: "SARG" en alemán significa "Ataúd", por lo que siempre tengo que sonreír cuando la gente habla de SARGABLE: ¿se puede poner en un ataúd? :-) –
la sargabilidad depende de su entorno. MySQL está documentado aquí: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html –