[Communicatie] Indexgebruiksprobleem wanneer sqlserver handelt als '%keyword%'

Stelling 1: Het percentage teken % wildcard-prefix zorgt ervoor dat SQL-queries de index stoppen en in plaats daarvan volledige tabel scannen. Deze uitspraak is populair

De conclusie is verkeerd

In feite is deze uitspraak niet erg accuraat. Het wildcard-prefix % maakt SQL-zoekopdrachten naar indexen extreem efficiënt, maar in de meeste gevallen gaat het toch naar de index (er is geen volledige tekstindex nodig, gewoon een normale index bouwen)

MAAK EEN NIET-GECLUSTERDE INDEX AAN [Ix_index NAAM] OP [dbo]. [wkf_ Tafelnaam]
(
[db_title]  ASC
)

Voer op dit moment uit

SELECTEER top 10 [db_id],[db_Summary],[db_AddDate],[db_title] VAN [bibliotheeknaam]. [dbo]. [wkf_database] waar [db_title]zoals '%dba%' volgorde per 1 beschrijving

Het queryplan wordt duidelijk weergegeven

Voordat de vergelijking wordt geïndexeerd:

Als uitzondering kunnen complexe query's De query-optimizer de index laten vallen ten gunste van volledige tabelscanning. Dit geldt niet alleen voor LIKE '%keyword%', maar ook gerelateerd aan querycomplexiteit

Stelling 2: Percentage % wildcard-prefixen zorgt ervoor dat SQL-queries indexeren in plaats van geen index

Deze uitspraak is zeer eenzijdig, en 99% van de index zal IO verminderen en de efficiëntie verbeteren vergeleken met het niet indexeren, maar de sleutelmatchactie nadat de index is gevonden is ook deels prestatie-intensief. Zoals te zien is in de twee bovenstaande figuren, als de zoekwoorden gemakkelijk te matchen zijn, vindt de volledige tabelscan snel de gegevens, en de indexscan bespaart niet genoeg tijd om de tijd die door de sleutelmatchactie wordt verbruikt te compenseren (de meeste online zoekopdrachten hebben dit probleem niet).
Behandeling:
1. Als je er niet om geeft, is het extra prestatieverbruik niet erg groot. En verschillende zoekwoorden hebben verschillende verbruik, maar sommige trefwoorden hebben dit probleem en kunnen genegeerd worden
2. Een betere manier is om een override-index te bouwen (ook wel een INCLUDE-index genoemd) als de omstandigheden dat toelaten. Premisse: a. De opslagruimte is voldoende, b beïnvloedt de DML-operaties niet significant, en c heeft geen grote velden in de overschreven index

MAAK EEN NIET-GECLUSTERDE INDEX AAN [Ix_index NAAM] OP [dbo]. [wkf_ Tafelnaam]
(
[db_title]  ASC
)
INCLUDE ( [db_id],[db_Summary],[db_AddDate])

Op dit moment is het uitvoeringsqueryplan als volgt, wat veel verfrissender is

Bovenstaande is wat ik nu kan bedenken voor SQLSERVER-verwerking SELECTEER * UIT TABELNAAM ZOALS '%Keyword %'