Cosa significa veramente la parola "SARGable"?

Gli utenti di SQL Server usano il termine "sargable" . Mi chiedo se esiste una definizione oggettiva e agnostica senza tempo per "sargable".

Ad esempio, WHERE foo LIKE '%bar%'molti dicono che non è possibile effettuare il sarginamento , ma alcuni RDBMS sono in grado di utilizzare gli indici su tali query . Che cosa significa quindi "non sargable" ?

Altri riferimenti

• Ciò che rende una dichiarazione SQL sargable?

Il termine "sargable" è stato introdotto per la prima volta da P. Griffiths Selinger et al. nel loro articolo del 1979 "Selezione del percorso di accesso in un sistema di gestione di database relazionali", pubblicato da ACM . Per i membri non ACM c'è una copia di quel documento su http://cs.stanford.edu/people/chrismre/cs345/rl/selinger.pdf

Il termine è definito in questo paragrafo:

Le scansioni dell'indice e del segmento ¹ possono facoltativamente accettare una serie di predicati, chiamati argomenti di ricerca (o SARGS), che vengono applicati a una tupla prima che venga restituita al chiamante RSI ² . Se la tupla soddisfa i predicati, viene restituita; in caso contrario la scansione continua fino a quando non trova una tupla che soddisfa il SARGS o esaurisce il segmento o l'intervallo di valori dell'indice specificato. Ciò riduce i costi eliminando il sovraccarico di effettuare chiamate RSI per le tuple che possono essere efficacemente rifiutate all'interno dell'RSS. Non tutti i predicati hanno la forma che può diventare SARGS. Un predicato di grandi dimensioni è uno di forma (o che può essere inserito nel modulo) "valore operatore comparativo colonna". I SARG sono espressi come espressione booleana di tali predicati in forma disgiuntiva normale.

In altre parole, un predicato di grandi dimensioni è tale che può essere risolto dal motore di archiviazione (metodo di accesso) osservando direttamente la tabella o il record dell'indice. Al contrario, un predicato non numerabile richiede un livello superiore del DBMS per agire. Ad esempio, il risultato di WHERE lastname = 'Doe'può essere deciso dal motore di archiviazione semplicemente guardando il contenuto del campo lastnamedi ciascun record. D'altra parte, WHERE UPPER(lastname) = 'DOE'richiede l'esecuzione di una funzione da parte del motore SQL, il che significa che il motore di archiviazione dovrà restituire tutte le righe che legge (purché corrispondano a possibili altri predicati di grandi dimensioni) al motore SQL per la valutazione, sostenendo costi aggiuntivi della CPU .

Dalla definizione originale si può vedere che i predicati di grandi dimensioni possono applicarsi non solo alle scansioni dell'indice, ma anche alle scansioni delle tabelle (segmento nella terminologia del sistema R), purché siano soddisfatte le condizioni "valore operatore comparativo di colonna" e pertanto possano essere valutato dal motore di archiviazione. Questo è davvero il caso di Db2, un discendente del Sistema R in molti modi :

I predicati di grandi dimensioni dell'indice non vengono utilizzati per raggruppare una ricerca, ma vengono valutati dall'indice se ne viene scelto uno, poiché le colonne coinvolte nel predicato fanno parte della chiave dell'indice. Questi predicati vengono inoltre valutati dal gestore dell'indice.

I predicati di grandi dimensioni dei dati sono predicati che non possono essere valutati dal gestore dell'indice, ma possono essere valutati da Data Management Services (DMS). In genere, questi predicati richiedono l'accesso a singole righe da una tabella di base. Se necessario, DMS recupererà le colonne necessarie per valutare il predicato,

Il fatto che nei predicati di grandi dimensioni di SQL Server-speak siano solo quelli che possono essere risolti utilizzando le ricerche di indice è probabilmente determinato dall'incapacità del suo motore di archiviazione di applicare tali predicati durante le scansioni delle tabelle.

I predicati di grandi dimensioni e non di grandi dimensioni sono talvolta descritti rispettivamente come predicati di "fase 1" e "fase 2" (questo deriva anche dalla terminologia Db2 ). I predicati della fase 1 possono essere valutati al livello più basso di elaborazione delle query, durante la lettura dei record di tabella o indice. Le righe che soddisfano le condizioni della fase 1, se presenti, vengono inviate al livello successivo, fase 2, della valutazione.

¹ - Il segmento nel Sistema R è l'archiviazione fisica delle tuple di una tabella; una scansione di segmento è in qualche modo equivalente a una scansione di tabella in altri DBMS.

² - RSI - RSS ³ Interface, un'interfaccia di query orientata alla tupla. La funzione di interfaccia rilevante per questa discussione è NEXT, che restituisce i predicati della query di corrispondenza della riga successiva.

³ - RSS, o Research Storage System, il sottosistema di archiviazione del sistema R.

Per me, SARGable significa che SQL Server può eseguire una ricerca dell'indice utilizzando i predicati della ricerca.

Non si può semplicemente dire che il DBMS può "sfruttare" un indice, perché con un predicato non numerabile, SQL Server potrebbe finire con la scansione di un indice non cluster.

Secondo Pro SQL Server Internals di Dmitri Korotkevitch :

Un predicato ABLE di Search ARgument è un predicato in cui SQL SERVER può utilizzare un'operazione di ricerca dell'indice, se esiste un indice.

Un predicato SARGable è un predicato in cui il server SQL può isolare il singolo valore o intervallo di valori chiave dell'indice da elaborare

Predicati SARGable includono i seguenti operatori: =, >, >=, <, <=, IN, BETWEEN, e LIKE( nel caso di allineamento prefisso )

Operatori non SARGable comprendono: NOT, NOT IN, <>, e LIKE( non del prefisso ), così come l'uso di funzioni o calcoli contro il tavolo, e conversioni di tipo in cui il tipo di dati non soddisfa l'indice creato.

Esempio :

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;

Ora corriamo:

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;

I risultati sono:

Diamo un'occhiata alle proprietà della query SARGable (Ricerca indice)

Query Optimizer è in grado di definire un limite nell'indice di inizio e fine. Ha un argomento di ricerca con cui interrogare.

Ora la query non SARGable:

È possibile vedere con l'inizio del predicato '% non ..%' non consentire a Query Optimizer di DEFINIRE un inizio, una fine o un intervallo nell'indice. Ora deve cercare in tutta la tabella (scansione).