[Komunikacja] Problem z wykorzystaniem indeksu, gdy sqlserver obsługuje np. '%keyword%'

Zdanie 1: Prefiks dzikiego znaku procent spowoduje, że zapytania SQL zatrzymają indeks i zamiast tego użyją pełnego skanowania tabel. To stwierdzenie jest popularne

Wniosek jest błędny

W rzeczywistości to stwierdzenie nie jest zbyt dokładne. Prefiks wildcard % sprawi, że wyszukiwanie indeksów SQL będzie bardzo wydajne, ale w większości przypadków nadal trafi do indeksu (nie jest wymagany pełny tekst, wystarczy zbudować zwykły indeks)

UTWÓRZ INDEKS NIEKLASTROWANY [Ix_index NAZWA] NA [dbo]. [wkf_ Nazwa stołu]
(
[db_title]  ASC
)

Wykonaj w tym momencie

WYBIERZ top 10 [db_id], [db_Summary],[db_AddDate],[db_title] Z [nazwa biblioteki]. [dbo]. [wkf_database] gdzie [db_title] jak '%dba%' uporządkowane przez 1 desc

Plan zapytania jest wyraźnie widoczny

Przed indeksowaniem porównania:

Wyjątkiem są złożone zapytania Optimalizator zapytań może porzucić indeks na rzecz pełnego skanowania tabel. Dotyczy to nie tylko LIKE '%keyword', ale także złożoności zapytań

Stwierdzenie 2: Percent% prefiksów wildcard sprawi, że zapytania SQL będą indeksowane, a nie ich nie

To stwierdzenie jest bardzo jednostronne i 99% indeksu obniży IO i poprawi efektywność w porównaniu do nieindeksowania, ale kluczowa dopasowość po znalezieniu indeksu jest również częściowo obciążająca wydajność. Jak pokazano na dwóch powyższych rysunkach, jeśli słowa kluczowe są łatwo dopasowane, pełne skanowanie tabeli szybko znajduje dane, a skanowanie indeksu nie oszczędza wystarczająco dużo czasu, by zrekompensować czas potrzebny na akcję dopasowania klucza (większość zapytań online nie ma tego problemu).
Leczenie:
1. Jeśli ci na tym nie zależy, dodatkowe zużycie wydajności nie jest duże. Różne słowa kluczowe mają różną popularność, ale niektóre mają ten problem i można je zignorować
2. Lepszym sposobem jest zbudowanie indeksu nadpisującego (znanego również jako indeks INKLUZY), jeśli warunki na to pozwalają. Założenie: a. Przestrzeń pamięci jest wystarczająca, b nie wpływa znacząco na operacje DML, a c nie ma dużych pól w nadpisanym indeksie

UTWÓRZ INDEKS NIEKLASTROWANY [Ix_index NAZWA] NA [dbo]. [wkf_ Nazwa stołu]
(
[db_title]  ASC
)
INCLUDE ( [db_id],[db_Summary],[db_AddDate])

Obecnie plan zapytań wykonawczych wygląda następująco, co jest znacznie bardziej odświeżające

Powyższe to właśnie przychodzi mi do głowy w kontekście przetwarzania SQLSERVER SELECT * FROM TABLENAME, np. '%Keyword %'