[Comunicazione] Problema di utilizzo dell'indice quando SQLSERVER gestisce come '%keyword%'

Affermazione 1: Il prefisso jolly % di segno percentuale farà sì che le query SQL interrompano l'indice e utilizzino invece la scansione completa delle tabelle. Questa affermazione è popolare

La conclusione è sbagliata

In realtà, questa affermazione non è molto accurata. Il prefisso jolly % renderà la ricerca SQL per indici estremamente efficiente, ma nella maggior parte dei casi andrà comunque all'indice (non è richiesto un indice integrale, basta costruire un indice normale)

CREA UN INDICE NON CLUSTERIZZATO [Ix_index NOME] SU [dbo]. [wkf_ Nome del tavolo]
(
[db_title]  ASC
)

Esegui in questo momento

SELECT top 10 [db_id],[db_Summary],[db_AddDate],[db_title] DA [nome della biblioteca]. [dbo]. [wkf_database] dove [db_title]come '%dba%' ordina di 1 desc

Il piano delle query è chiaramente visualizzato

Prima che il confronto venga indicizzato:

Come eccezione, query complesse L'ottimizzatore di query può abbandonare l'indice a favore della scansione completa delle tabelle. Questo non vale solo per LIKE '%keyword%', ma anche per la complessità delle query

Affermazione 2: I prefissi di porcentuale di wild card faranno in modo che le query SQL si indichino invece di nessun indice

Questa affermazione è molto unilaterale, e il 99% dell'indice ridurrà l'IO e migliorerà l'efficienza rispetto al non indicizzare, ma l'azione di abbinamento delle chiavi dopo aver trovato l'indice è anche in parte un consumo. Come mostrato nelle due figure sopra, se le parole chiave sono facilmente abbinabili, la scansione completa della tabella trova rapidamente i dati e la scansione dell'indice non risparmia abbastanza tempo per compensare il tempo impiegato dall'azione di abbinamento delle chiavi (la maggior parte delle query online non ha questo problema).
Trattamento:
1. Se non ti interessa, il consumo extra di prestazioni non è molto elevato. E le diverse parole chiave hanno un consumo differente, ma alcune hanno questo problema e possono essere ignorate
2. Un modo migliore è costruire un indice di override (noto anche come indice INCLUDE) se le condizioni lo permettono. Premessa: a. Lo spazio di archiviazione è sufficiente, b non influisce significativamente sulle operazioni DML e c non ha campi grandi nell'indice sovrascritto

CREA UN INDICE NON CLUSTERIZZATO [Ix_index NOME] SU [dbo]. [wkf_ Nome del tavolo]
(
[db_title]  ASC
)
INCLUDE ( [db_id], db_Summary],[db_AddDate])

Al momento, il piano di esecuzione delle query è il seguente, molto più rinfrescante

Quanto sopra è ciò che mi viene in mente ora per l'elaborazione SQLSERVER, SELEZIONA * DA NOME TABELLA COME '%Keyword %'