[Comunicación] Problema de utilización del índice cuando SQL Servers maneja como '%keyword%'

Declaración 1: El prefijo comodín de porcentaje % de signo hará que las consultas SQL detengan el índice y en su lugar utilicen el escaneo completo de tablas. Esta afirmación es popular

La conclusión es incorrecta

De hecho, esta afirmación no es muy precisa. El prefijo comodín % hará que la búsqueda SQL de índices sea extremadamente eficiente, pero en la mayoría de los casos seguirá llegando al índice (no se requiere un índice completo, solo construye un índice normal).

CREAR UN ÍNDICE NO AGRUPADO [NOMBRE Ix_index] EN [dbo]. [wkf_ Nombre de la mesa]
(
[db_title]  ASC
)

Ejecutar en este momento

SELECT top 10 [db_id],[db_Summary],[db_AddDate],[db_title] DE [nombre de la biblioteca]. [dbo]. [wkf_database] donde [db_title] como '%dba%' ordenan por 1 desc

El plan de consulta se muestra claramente

Antes de que se indexe la comparación:

Como excepción, consultas complejas El optimizador de consultas puede abandonar el índice en favor del escaneo completo de tablas. Esto no solo ocurre con LIKE '%keyword%', sino también relacionado con la complejidad de la consulta

Declaración 2: Los prefijos porcentual de wildcard harán que las consultas SQL indexen en lugar de no indexar nada

Esta afirmación es muy parcial, y el 99% del índice reducirá las IO y mejorará la eficiencia en comparación con no indexar, pero la acción de emparejamiento de claves tras encontrar el índice también consume en parte el rendimiento. Como se muestra en las dos figuras anteriores, si las palabras clave se emparejan fácilmente, el escaneo completo de la tabla encuentra rápidamente los datos, y el escaneo de índices no ahorra suficiente tiempo para compensar el tiempo que consume la acción de coincidencia de claves (la mayoría de las consultas online no tienen este problema).
Tratamiento:
1. Si no te importa, el consumo extra de rendimiento no es muy grande. Y diferentes palabras clave tienen un consumo distinto, pero algunas tienen este problema y pueden ignorarse
2. Una mejor forma es construir un índice de anulación (también conocido como índice INCLUDE) si las condiciones lo permiten. Premisa: a. El espacio de almacenamiento es suficiente, b no afecta significativamente a las operaciones DML, y c no tiene campos grandes en el índice sobreescrito

CREAR UN ÍNDICE NO AGRUPADO [NOMBRE Ix_index] EN [dbo]. [wkf_ Nombre de la mesa]
(
[db_title]  ASC
)
INCLUYE ( [db_id], db_Summary],[db_AddDate])

Por ahora, el plan de consulta de ejecución es el siguiente, lo cual resulta mucho más refrescante

Lo anterior es lo que se me ocurre ahora para el procesamiento de SQLSERVER SELECCIONA * DESDE NOMBRE DE TABLA, COMO '%Keyword %'