En bases de datos relacionales , se dice que una condición (o predicado) en una consulta es sargable si el motor DBMS puede aprovechar un índice para acelerar la ejecución de la consulta. El término se deriva de una contracción de Search ARGument ABLE . Fue utilizado por primera vez por investigadores de IBM como una contracción de Search ARGument y ha llegado a significar simplemente "se puede buscar mediante un índice". 1 [1] [2]
Para los optimizadores de consultas de bases de datos , sargable es una propiedad importante en las cargas de trabajo OLTP porque sugiere que se puede obtener un buen plan de consulta mediante una simple consulta de coincidencia heurística 2 con índices en lugar de una búsqueda compleja, que consume mucho tiempo y basada en costos, [1] por lo que a menudo se desea escribir consultas sargables. Una consulta que no es sargable se conoce como una consulta no sargable y generalmente tiene un efecto negativo en el tiempo de consulta, por lo que uno de los pasos en la optimización de consultas es convertirlas para que sean sargables. El efecto es similar a buscar un término específico en un libro que no tiene índice, comenzando en la página uno cada vez, en lugar de saltar a una lista de páginas específicas identificadas en un índice.
La situación típica que hace que una consulta SQL no sea compatible con el formato de búsqueda es incluir en la cláusula WHERE una función que opera sobre un valor de columna. La cláusula WHERE no es la única cláusula en la que la compatibilidad con el formato de búsqueda puede ser importante; también puede tener un efecto en las cláusulas ORDER BY, GROUP BY y HAVING. La cláusula SELECT, por otro lado, puede contener expresiones que no sean compatibles con el formato de búsqueda sin afectar negativamente el rendimiento.
Algunos sistemas de gestión de bases de datos, como PostgreSQL, admiten índices funcionales. En teoría, un índice es simplemente una asignación entre un valor y una o más ubicaciones. Con un índice funcional, el valor almacenado en el índice es el resultado de la función especificada cuando se crea el índice. Esta capacidad amplía lo que se puede analizar más allá de las expresiones de columnas base.
=, >, <, >=, <=, BETWEEN, LIKE, IS [NOT] NULL, IN<>, NOT, NOT IN, NOT LIKEWHERELas cláusulas que se pueden sargar normalmente tienen valores de campo a la izquierda del operador y valores escalares o expresiones en el lado derecho del operador.
No sargable:
SELECCIONAR * DE miTabla DONDE SQRT ( miCampoIntegrado ) > 11.7 Esto no se puede modificar porque myIntField está integrado en una función. Si hubiera índices disponibles en myIntField, no se podrían usar. Además, se llamaría a cada registro en myTable.SQRT()
Versión Sargable:
SELECCIONAR * DE miTabla DONDE miCampoInt > 11.7 * 11.7 Esto se puede analizar porque myIntField NO está incluido en una función, lo que hace que cualquier índice disponible en myIntField sea potencialmente utilizable. Además, la expresión se evalúa solo una vez, en lugar de para cada registro de la tabla.
WHERE... LIKElas cláusulas que se pueden modificar tienen valores de campo a la izquierda del operador y LIKEcadenas de texto que no comienzan con a %la derecha.
No sargable:
SELECT * FROM myTable WHERE myNameField LIKE '%Wales%' -- Comienza con %, no es sargable Esto no se puede ejecutar en Sarg. Debe examinar cada fila para encontrar los campos que contienen la subcadena 'Wales'en cualquier posición.
Versión Sargable:
SELECT * FROM myTable WHERE myNameField LIKE 'Jimmy%' -- No comienza con %, sargable Esto se puede analizar mediante Sarg. Puede usar un índice para buscar todos los valores de myNameField que comiencen con la subcadena 'Jimmy'.