[Kommunikation] Indexudnyttelsesproblem, når sqlserver håndterer som '%keyword%'

Udsagn 1: Procenttegn % wildcard-præfikset vil få SQL-forespørgsler til at stoppe indekset og i stedet bruge fuld tabelscanning. Denne udtalelse er populær

Konklusionen er forkert

Faktisk er denne sætning ikke særlig præcis. Joker-præfikset % vil gøre SQL-søgning efter indekser ekstremt effektiv, men i de fleste tilfælde vil det stadig gå til indekset (der kræves ikke et fuldtekstindeks, man opbygger blot et normalt indeks)

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

Udfør på dette tidspunkt

VÆLG top 10 [db_id],[db_Summary],[db_AddDate],[db_title] FRA [bibliotekets navn]. [DBO]. [wkf_database] hvor [db_title]som '%dba%' rækkefølge efter 1 beskrivelse

Forespørgselsplanen vises tydeligt

Før sammenligningen indekseres:

Som undtagelse kan komplekse forespørgsler Forespørgselsoptimeringen opgive indekset til fordel for fuld tabelscanning. Dette gælder ikke kun for SOM '%keyword%', men også relateret til forespørgselskompleksitet

Sætning 2: Procentdel % af wildcard-præfikser vil få SQL-forespørgsler til at indeksere i stedet for ingen indeks

Denne udtalelse er meget ensidig, og 99% af indekset vil reducere IO og forbedre effektiviteten sammenlignet med ikke indeksering, men nøglematchningshandlingen efter indekset er fundet er også delvist præstationskrævende. Som vist i de to figurer ovenfor, hvis nøgleordene let matches, finder den fulde tabelscanning hurtigt dataene, og indeksscanningen sparer ikke nok tid til at kompensere for den tid, der bruges på nøglematchningshandlingen (de fleste online forespørgsler har ikke dette problem).
Behandling:
1. Hvis du ikke bekymrer dig om det, er det ekstra ydelsesforbrug ikke særlig stort. Og forskellige nøgleord har forskelligt forbrug, men nogle nøgleord har dette problem og kan ignoreres
2. En bedre måde er at opbygge et overstyringsindeks (også kendt som et INCLUDE-indeks), hvis forholdene tillader det. Præmis: a. Lagerpladsen er tilstrækkelig, b påvirker ikke DML-operationerne væsentligt, og c har ikke store felter i det overskrevne indeks

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

På nuværende tidspunkt er udførelsesforespørgselsplanen som følger, hvilket er meget mere forfriskende

Ovenstående er, hvad jeg nu kan komme i tanke om for SQLSERVER-behandling VÆLG * FRA TABELNAVN SOM '%Keyword %'