Was bedeutet das Wort "SARGable" wirklich?

SQL Server-Benutzer verwenden den Begriff "sargable" . Ich frage mich, ob es eine objektive implementierungsunabhängige zeitlose Definition für "sargable" gibt.

Zum Beispiel WHERE foo LIKE '%bar%'wird von vielen gesagt, dass sie nicht sargable sind , aber einige RDBMSs sind in der Lage, Indizes für solche Abfragen zu verwenden . Was heißt dann "nicht sargbar" ?

Weitere Referenzen

• Was macht eine SQL-Anweisung so wertvoll?

Der Begriff "sargable" wurde erstmals von P. Griffiths Selinger et al. in ihrem 1979 von ACM veröffentlichten Aufsatz "Zugriffspfadauswahl in einem relationalen Datenbankverwaltungssystem" . Für Nicht-ACM-Mitglieder gibt es eine Kopie dieses Papiers unter http://cs.stanford.edu/people/chrismre/cs345/rl/selinger.pdf

Der Begriff wird in diesem Absatz definiert:

Sowohl Index- als auch Segment- ^1- Scans können optional eine Reihe von Prädikaten, sogenannte Suchargumente (oder SARGS), verwenden, die auf ein Tupel angewendet werden, bevor es an den RSI ^2- Aufrufer zurückgegeben wird. Wenn das Tupel die Prädikate erfüllt, wird es zurückgegeben. Andernfalls wird der Scan fortgesetzt, bis entweder ein Tupel gefunden wird, das den SARGS-Wert erfüllt, oder das Segment oder den angegebenen Indexwertebereich erschöpft. Dies reduziert die Kosten, da der Aufwand für RSI-Aufrufe für Tupel entfällt, die innerhalb des RSS effizient abgelehnt werden können. Nicht alle Prädikate haben die Form, die zu SARGS werden kann. Ein sargierbares Prädikat ist eines der Formulare (oder kann in das Formular eingefügt werden) "Spaltenvergleichsoperatorwert". SARGs werden als boolescher Ausdruck solcher Prädikate in disjunktiver Normalform ausgedrückt.

Mit anderen Worten, ein sargables Prädikat ist so beschaffen, dass es von der Speicher-Engine (Zugriffsmethode) aufgelöst werden kann, indem die Tabelle oder der Indexsatz direkt betrachtet werden. Umgekehrt erfordert ein nicht sargierbares Prädikat eine höhere Ebene des DBMS, um Maßnahmen zu ergreifen. Zum Beispiel kann das Ergebnis von WHERE lastname = 'Doe'durch die Speicher-Engine bestimmt werden, indem einfach der Inhalt des Feldes lastnamejedes Datensatzes betrachtet wird. WHERE UPPER(lastname) = 'DOE'Erfordert andererseits die Ausführung einer Funktion durch die SQL-Engine. Dies bedeutet, dass die Speicher-Engine alle gelesenen Zeilen (sofern sie mit möglichen anderen, aufladbaren Prädikaten übereinstimmen) zur Auswertung an die SQL-Engine zurücksenden muss, was zusätzliche CPU-Kosten verursacht .

Aus der ursprünglichen Definition geht hervor, dass sargable Prädikate nicht nur für Index-Scans, sondern auch für Tabellen-Scans (Segment in System R-Terminologie) gelten können, sofern die Bedingungen "Spaltenvergleich-Operatorwert" erfüllt sind und daher erfüllt werden können von der Speicher-Engine ausgewertet. Dies ist in der Tat bei Db2, einem Nachkommen von System R, in vielerlei Hinsicht der Fall :

Index-sargable-Prädikate werden nicht zur Klammerung einer Suche verwendet, sondern werden aus dem Index ausgewertet, wenn einer ausgewählt wird, da die am Prädikat beteiligten Spalten Teil des Indexschlüssels sind. Diese Prädikate werden auch vom Indexmanager ausgewertet.

Data-Sargable-Prädikate sind Prädikate, die nicht vom Indexmanager, sondern von Data Management Services (DMS) ausgewertet werden können. In der Regel erfordern diese Prädikate den Zugriff auf einzelne Zeilen aus einer Basistabelle. Bei Bedarf ruft DMS die Spalten ab, die zur Auswertung des Vergleichselements erforderlich sind.

Die Tatsache, dass sargable Prädikate in SQL Server-Sprache nur solche sind, die mithilfe von Indexsuchen aufgelöst werden können, wird wahrscheinlich durch die Unfähigkeit des Speicher-Moduls bestimmt, solche Prädikate während Tabellensuchen anzuwenden.

Sargable und nicht-sargable Prädikate werden manchmal als "Stadium 1" - bzw. "Stadium 2" -Prädikate beschrieben (dies stammt auch aus der Db2-Terminologie ). Prädikate der Stufe 1 können auf der niedrigsten Ebene der Abfrageverarbeitung ausgewertet werden, während Tabellen- oder Indexdatensätze gelesen werden. Zeilen, die den Bedingungen von Stufe 1 entsprechen, werden an die nächste Stufe 2 der Bewertung gesendet.

¹ - Segment in System R ist der physische Speicher der Tupel einer Tabelle; Ein Segment-Scan entspricht in etwa einem Tabellenscan in anderen DBMS.

² - RSI - RSS ³ Interface, eine Tupel-orientierte Abfrageoberfläche. Die für diese Diskussion relevante Schnittstellenfunktion ist NEXT, die die Abfrageprädikate für die nächste Zeile zurückgibt.

³ - RSS oder Research Storage System, das Speichersubsystem von System R.

Für mich bedeutet SARGable, dass SQL Server eine Indexsuche mit Ihren Suchprädikaten durchführen kann.

Sie können nicht einfach sagen, dass das DBMS einen Index "ausnutzen" kann, da SQL Server bei einem nicht sargierbaren Prädikat möglicherweise einen nicht gruppierten Index scannt.

Laut Pro SQL Server Internals von Dmitri Korotkevitch :

Ein Search ARgument ABLE-Prädikat ist eines, bei dem SQL SERVER eine Indexsuchoperation verwenden kann, wenn ein Index vorhanden ist.

Ein SARGable-Prädikat ist eines, bei dem SQL Server den einzelnen Wert oder den Bereich der zu verarbeitenden Indexschlüsselwerte isolieren kann

Sargable Prädikate umfassen die folgenden Operatoren: =, >, >=, <, <=, IN, BETWEEN, und LIKE( im Fall von prefix Anpassung )

Sargable Non-Operatoren sind: NOT, NOT IN, <>, und LIKE( nicht Prefix Matching ), sowie die Verwendung von Funktionen oder Berechnungen gegen den Tisch und Typkonvertierungen , wo der Datentyp nicht den Index erstellt nicht erfüllt.

Beispiel :

WHERE name like 'SARGable%'
WHERE name like '%non-SARGable%'

Demo :

DROP TABLE dbo.Testing;
GO

CREATE TABLE Testing (
    WeirdDatatype   int NOT NULL,
    SomethingElse   char(200)
);

CREATE NONCLUSTERED INDEX IDX_ALWAYS_SARGable
    ON dbo.Testing( SomethingElse);

CREATE NONCLUSTERED INDEX IDX_NOT_ALWAYS_SARGable
    ON dbo.Testing(SomethingElse);

INSERT INTO dbo.Testing
        ( WeirdDatatype, SomethingElse )
SELECT TOP 1000 m.message_id, CONVERT(char(200), m.text)
FROM sys.messages AS m;

Jetzt laufen wir:

SELECT *
FROM dbo.Testing AS t
WHERE  t.WeirdDatatype = 1001;
SELECT *
FROM dbo.Testing AS t
WHERE t.SomethingElse LIKE 'Line%'
SELECT *
FROM dbo.Testing AS t
WHERE t.SomethingElse LIKE '%Line%'
     AND t.WeirdDatatype = 1001;

Die Ergebnisse sind:

Schauen wir uns die Eigenschaften der SARGable-Abfrage an (Index Seek)

Der Abfrageoptimierer kann ein Limit im Index eines Starts und Endes definieren. Es gibt ein Suchargument, mit dem abgefragt werden kann.

Nun die Nicht-SARGable-Abfrage:

Sie können am Anfang des Prädikats sehen, dass '% non ..%' es dem Abfrageoptimierer nicht ermöglicht, einen Anfang und ein Ende oder einen Bereich im Index zu DEFINIEREN. Es muss nun die ganze Tabelle durchsuchen (scan).