[Comunicare] Problemă de utilizare a indexului când SQLSERVER gestionează "%keyword%"

Afirmația 1: Prefixul wildcard procentual de semn procentual va determina interogările SQL să oprească indexul și să folosească în schimb scanarea completă a tabelelor. Această afirmație este populară

Concluzia este greșită

De fapt, această afirmație nu este foarte exactă. Prefixul wildcard % va face căutarea SQL pentru indexuri extrem de eficientă, dar în majoritatea cazurilor tot va ajunge la index (nu este necesar un index complet, doar construiește un index normal).

CREEAZĂ UN INDEX NECLUSTERAT [NUME Ix_index] PE [dbo]. [wkf_ Numele tabelului]
(
[db_title]  ASC
)

Executați în acest moment

SELECT top 10 [db_id],[db_Summary],[db_AddDate],[db_title] DIN [numele bibliotecii]. [dbo]. [wkf_database] unde [db_title]ca '%dba%' ordonează cu 1 desc

Planul de interogare este afișat clar

Înainte ca comparația să fie indexată:

Ca excepție, interogări complexe Optimizatorul de interogări poate abandona indexul în favoarea scanării complete a tabelelor. Acest lucru nu este valabil doar pentru LIKE '%keyword', ci și pentru complexitatea interogărilor

Afirmația 2: Procentul % de prefixe wildcard vor face ca interogările SQL să fie indexate, nu niciun index

Această afirmație este foarte unilaterală, iar 99% din indice va reduce IO și va îmbunătăți eficiența comparativ cu neindexarea, dar acțiunea de potrivire a cheilor după ce indicele este găsit este parțial consumatoare de performanță. Așa cum se arată în cele două figuri de mai sus, dacă cuvintele-cheie sunt ușor de potrivit, scanarea completă a tabelului găsește rapid datele, iar scanarea indexului nu economisește suficient timp pentru a compensa timpul consumat de acțiunea de potrivire a cheilor (majoritatea interogărilor online nu au această problemă).
Tratament:
1. Dacă nu-ți pasă, consumul suplimentar de performanță nu este foarte mare. Și diferite cuvinte cheie au un consum diferit, dar unele cuvinte cheie au această problemă și pot fi ignorate
2. O metodă mai bună este să se construiască un indice de suprascriere (cunoscut și ca indice INCLUDE) dacă condițiile permit. Premisă: a. Spațiul de stocare este suficient, b nu afectează semnificativ operațiunile DML, iar c nu are câmpuri mari în indexul suprascris

CREEAZĂ UN INDEX NECLUSTERAT [NUME Ix_index] PE [dbo]. [wkf_ Numele tabelului]
(
[db_title]  ASC
)
INCLUDE ( [db_id],[db_Summary],[db_AddDate])

În acest moment, planul de interogare de execuție este următorul, ceea ce este mult mai revigorant

Cele de mai sus sunt cele la care mă pot gândi acum pentru procesarea SQLSERVER, SELECT * FROM TABLENAME, CUM AR FI '%Keyword %'