[Viestintä] Indeksin käyttöongelma, kun sqlserver käsittelee esimerkiksi '%keyword%'

Väite 1: Prosenttimerkki % villikorttietuliite saa SQL-kyselyt pysäyttämään indeksin ja käyttämään sen sijaan täyttä taulukon skannatusta. Tämä väite on suosittu

Johtopäätös on väärä

Itse asiassa tämä väite ei ole kovin tarkka. Jokerikortti-% -etuliite tekee SQL-indeksin hausta erittäin tehokkaaksi, mutta useimmissa tapauksissa se menee silti indeksiin (kokotekstiindeksiä ei tarvita, rakennetaan vain normaali indeksi).

LUO EI-KLUSTEROITU INDEKSI [Ix_index NAME] [dbo]:SSA. [wkf_ Pöydän nimi]
(
[db_title]  ASC
)

Suorita tässä vaiheessa

VALITSE top 10 [db_id],[db_Summary],[db_AddDate],[db_title] FROM [kirjaston nimi]. [dbo]. [wkf_database] missä [db_title]kuten '%dba%' järjestys yhdellä desc

Kyselysuunnitelma näkyy selvästi

Ennen kuin vertailu indeksoidaan:

Poikkeuksena monimutkaiset kyselyt Kyselyoptimaattori voi hylätä indeksin ja siirtyä täydelliseen taulukkoskannaukseen. Tämä ei koske vain LIKE '%keyword%' -tyyppistä, vaan myös kyselyn monimutkaisuutta

Väite 2: Prosentuaalinen % villikorttietuliitteet tekevät SQL-kyselyistä indeksin sen sijaan, että ei lainkaan indeksiä

Tämä väite on hyvin yksipuolinen, ja 99 % indeksistä vähentää IO:ta ja parantaa tehokkuutta verrattuna indeksoimatta jättämiseen, mutta keskeinen vastaavuustoimi indeksin löytämisen jälkeen on myös osittain suorituskykyä kuluttava. Kuten yllä olevissa kahdessa kuvassa näkyy, jos avainsanat on helppo yhdistää, koko taulukon skannaus löytää tiedot nopeasti, eikä indeksiskannaus säästä tarpeeksi aikaa korvatakseen avainten yhdistämisen kulumaa aikaa (useimmissa verkkokyselyissä tätä ongelmaa ei ole).
Hoito:
1. Jos et välitä siitä, ylimääräinen suorituskyvyn kulutus ei ole kovin suuri. Ja eri avainsanoilla on erilainen kulutus, mutta joillakin avainsanoilla on tämä ongelma ja ne voi jättää huomiotta
2. Parempi tapa on rakentaa ohitusindeksi (tunnetaan myös nimellä INCLUDE-indeksi), jos olosuhteet sen sallivat. Lähtökohta: a. Tallennustila on riittävä, b ei merkittävästi vaikuta DML-operaatioihin, eikä c:llä ole suuria kenttiä ylikirjoitetussa indeksissä

LUO EI-KLUSTEROITU INDEKSI [Ix_index NAME] [dbo]:SSA. [wkf_ Pöydän nimi]
(
[db_title]  ASC
)
INCLUDE ( [db_id],[db_Summary],[db_AddDate])

Tällä hetkellä suorituskyselysuunnitelma on seuraava, mikä on paljon virkistävämpää

Yllä oleva on se, mitä keksin nyt SQLSERVER-prosessoinnista VALITSE * TAULUNIMESTÄ KUTEN '%Keyword %'