[Зв'язок] Проблема використання індексу при обробці sqlserver на кшталт '%keyword%'

Твердження 1: Префікс Percent-sign % wildcard змусить SQL запити зупинити індекс і натомість використовувати сканування повної таблиці. Це твердження популярне

Висновок неправильний

Насправді це твердження не дуже точне. Префікс wildcard % робить пошук індексів у SQL надзвичайно ефективним, але в більшості випадків він все одно йде до індексу (не потрібен повний індекс, просто створіть звичайний індекс).

СТВОРИТИ НЕКЛАСТЕРИЗОВАНИЙ ІНДЕКС [Ix_index NAME] НА [dbo]. [wkf_ Назва столу]
(
[db_title]  ASC
)

Виконати в цей час

ВИБЕРІТЬ топ-10 [db_id],[db_Summary],[db_AddDate],[db_title] З [назва бібліотеки]. [DBO]. [wkf_database] де [db_title]подібний '%dba%' до 1 desc

План запиту чітко відображається

Перед індексуванням порівняння:

Як виняток, складні запити Оптимізатор запитів може відмовитися від індексу на користь повного сканування таблиці. Це стосується не лише LIKE '%keyword%', а й стосується складності запитів

Твердження 2: Percent% префікси wildcard зроблять SQL-запити індексними, а не відсутніми

Це твердження дуже однобічне, і 99% індексу зменшить IO та підвищить ефективність порівняно з відсутністю індексації, але дія підбору ключів після пошуку індексу також частково вимагає продуктивності. Як показано на двох рисунках вище, якщо ключові слова легко підібрати, повне сканування таблиці швидко знаходить дані, і індексне сканування не дозволяє компенсувати час, витрачений на дію підбору ключів (більшість онлайн-запитів не мають такої проблеми).
Лікування:
1. Якщо вам це байдуже, додаткове споживання продуктивності не дуже велике. І різні ключові слова мають різне споживання, але деякі ключові слова мають цю проблему і їх можна ігнорувати
2. Кращий спосіб — побудувати індекс перевизначення (також відомий як індекс INCLUDE), якщо умови це дозволяють. Передумова: a. Обсяг зберігання достатній, b суттєво не впливає на операції DML, і c не має великих полів у перезаписаному індексі

СТВОРИТИ НЕКЛАСТЕРИЗОВАНИЙ ІНДЕКС [Ix_index NAME] НА [dbo]. [wkf_ Назва столу]
(
[db_title]  ASC
)
INCLUDE ( [db_id],[db_Summary],[db_AddDate])

На даний момент план виконання запиту виглядає так, що є набагато свіжішим

Наведене вище — це те, що я зараз можу уявити для обробки SQLSERVER SELECT * З НАЗВИ ТАБЛИЦІ, НАПРИКЛАД '%Keyword %'