[Kommunikation] Indexauslastungsproblem, wenn SQL Server wie '%Keyword%' verarbeitet wird

Aussage 1: Das Präfix Prozentzeichen % Wildcard-Präfix führt dazu, dass SQL-Abfragen den Index stoppen und stattdessen Full Table Scanning verwenden. Diese Aussage ist beliebt

Das Fazit ist falsch

Tatsächlich ist diese Aussage nicht sehr genau. Das Joker-%-Präfix macht die SQL-Suche nach Indizes extrem effizient, aber in den meisten Fällen geht es trotzdem in den Index (kein Volltextindex ist erforderlich, man baut einfach einen normalen Index)

ERSTELLEN SIE EINEN NICHT-GRUPPIERTEN INDEX [Ix_index NAME] AUF [dbo]. [wkf_ Tischname]
(
[db_title]  ASC
)

Ausführen Sie zu diesem Zeitpunkt

WÄHLEN SIE die Top 10 [db_id],[db_Summary],[db_AddDate],[db_title] AUS [Bibliotheksname]. [dbo]. [wkf_database] Wo [db_title] wie '%dba%' Reihenfolge nach 1 Beschreibung

Der Abfrageplan ist klar dargestellt

Vor dem Vergleich:

Als Ausnahme kann komplexe Abfragen erfolgen: Der Abfrageoptimierer kann den Index zugunsten vollständiger Tabellenscans aufgeben. Das gilt nicht nur für LIKE '%keyword%', sondern hängt auch mit der Abfragekomplexität zusammen

Aussage 2: Prozentualer % von Wildcard-Präfixen führen dazu, dass SQL-Abfragen indexiert werden, statt ohne Index

Diese Aussage ist sehr einseitig, und 99 % des Index reduzieren IO und verbessern die Effizienz im Vergleich zum Nicht-Indexieren, aber die Schlüssel-Matching-Aktion nach dem Finden des Index ist ebenfalls teilweise leistungsaufwendig. Wie in den beiden obigen Abbildungen gezeigt, findet der vollständige Tabellen-Scan, wenn die Schlüsselwörter leicht zugeordnet sind, schnell die Daten, und der Index-Scan spart nicht genug Zeit, um die für die Schlüsselzuordnungsaktion benötigte Zeit auszugleichen (die meisten Online-Abfragen haben dieses Problem nicht).
Behandlung:
1. Wenn es dir egal ist, ist der zusätzliche Leistungsverbrauch nicht sehr groß. Und verschiedene Schlüsselwörter werden unterschiedlich konsumiert, aber einige Schlüsselwörter haben dieses Problem und können ignoriert werden
2. Eine bessere Methode ist es, einen Override-Index (auch INCLUDE-Index genannt) zu erstellen, wenn die Bedingungen es erlauben. Prämisse: a. Der Speicherplatz ist ausreichend, b beeinflusst die DML-Operationen nicht wesentlich, und c hat keine großen Felder im überschriebenen Index

ERSTELLEN SIE EINEN NICHT-GRUPPIERTEN INDEX [Ix_index NAME] AUF [dbo]. [wkf_ Tischname]
(
[db_title]  ASC
)
INCLUDE ( [db_id],[db_Summary],[db_AddDate])

Derzeit sieht der Ausführungsabfrageplan wie folgt aus, was deutlich erfrischender ist

Das oben Genannte fällt mir jetzt ein, wenn SQLSERVER SELECT * AUS TABLENAME WIE '%Keyword %' verarbeitet