[Kommunikasjon] Indeksutnyttelsesproblem når sqlserver håndterer som '%nøkkelord%'

Utsagn 1: Prosent-tegn % wildcard-prefikset vil få SQL-spørringer til å stoppe indeksen og i stedet bruke full tabellskanning. Denne uttalelsen er populær

Konklusjonen er feil

Faktisk er ikke denne påstanden særlig nøyaktig. Jokerprefikset % vil gjøre SQL-søk etter indekser ekstremt effektivt, men i de fleste tilfeller vil det fortsatt gå til indeksen (ingen fulltekstindeks kreves, bare bygg en vanlig indeks)

OPPRETT IKKE-KLYNGET INDEKS [Ix_index navn] PÅ [dbo]. [wkf_ Bordnavn]
(
[db_title]  ASC
)

Gjennomfør på dette tidspunktet

VELG topp 10 [db_id],[db_Summary],[db_AddDate],[db_title] FRA [biblioteknavn]. [dbo]. [wkf_database] hvor [db_title] som '%dba%' orden etter 1 beskrivelse

Spørringsplanen vises tydelig

Før sammenligningen indekseres:

Som et unntak, komplekse spørringer Spørringsoptimalisatoren kan forlate indeksen til fordel for full tabellskanning. Dette gjelder ikke bare for LIKE '%nøkkelord%', men også relatert til spørringskompleksitet

Utsagn 2: Prosent % wildcard-prefikser vil gjøre SQL-spørringer indeksert i stedet for ingen indeks

Denne påstanden er svært ensidig, og 99 % av indeksen vil redusere IO og forbedre effektiviteten sammenlignet med å ikke indeksere, men nøkkelmatchingshandlingen etter at indeksen er funnet er også delvis ytelseskrevende. Som vist i de to figurene ovenfor, hvis nøkkelordene enkelt kan matches, finner hele tabellskanningen raskt dataene, og indeksskanningen sparer ikke nok tid til å kompensere for tiden som brukes på nøkkelmatchingshandlingen (de fleste nettbaserte spørringer har ikke dette problemet).
Behandling:
1. Hvis du ikke bryr deg om det, er ikke det ekstra ytelsesforbruket særlig stort. Og ulike nøkkelord har ulikt forbruk, men noen nøkkelord har dette problemet og kan ignoreres
2. En bedre måte er å bygge en overstyringsindeks (også kjent som en INCLUDE-indeks) hvis forholdene tillater det. Premiss: a. Lagringsplassen er tilstrekkelig, b påvirker ikke DML-operasjonene vesentlig, og c har ikke store felt i den overskrevne indeksen

OPPRETT IKKE-KLYNGET INDEKS [Ix_index navn] PÅ [dbo]. [wkf_ Bordnavn]
(
[db_title]  ASC
)
INKLUDER ( [db_id],[db_Summary],[db_AddDate])

På dette tidspunktet er utførelsesplanen for spørringen som følger, noe som er mye mer forfriskende

Ovenstående er det jeg kan tenke meg nå for SQLSERVER som behandler VELG * FRA TABELLNAVN SOM '%Keyword %'