[Comunicação] Problema de utilização de índice quando o SQL Servers lida com '%palavra-chave%'

Declaração 1: O prefixo de curinga percentual de sinal % fará com que as consultas SQL parem o índice e, em vez disso, usem a varredura completa de tabelas. Essa afirmação é popular

A conclusão está errada

Na verdade, essa afirmação não é muito precisa. O prefixo coringa % torna a busca SQL por índices extremamente eficiente, mas na maioria dos casos ainda vai para o índice (não é necessário um índice em texto completo, basta construir um índice normal)

CRIE ÍNDICE NÃO AGRUPADO [Ix_index NOME] NO [dbo]. [wkf_ Nome da Mesa]
(
[db_title]  ASC
)

Execute agora

SELECT top 10 [db_id],[db_Summary],[db_AddDate],[db_title] DE [nome da biblioteca]. [dbo]. [wkf_database] onde [db_title] como '%dba%' ordenam por 1 desc

O plano de consulta é claramente exibido

Antes que a comparação seja indexada:

Como exceção, consultas complexas O otimizador de consultas pode abandonar o índice em favor da varredura completa da tabela. Isso não ocorre apenas com o LIKE '%palavra-chave%', mas também relacionado à complexidade da consulta

Declaração 2: Prefixos de porcentagem % de wildcard farão com que as consultas SQL indexem em vez de nenhum índice

Essa afirmação é muito unilateral, e 99% do índice reduzirá as E/S e melhorará a eficiência em comparação com não indexar, mas a ação de correspondência de chaves após a localização do índice também consome em parte o desempenho. Como mostrado nas duas figuras acima, se as palavras-chave forem facilmente correspondidas, a varredura completa da tabela rapidamente encontra os dados, e a varredura de índice não economiza tempo suficiente para compensar o tempo gasto pela ação de correspondência de chaves (a maioria das consultas online não apresenta esse problema).
Tratamento:
1. Se você não se importa, o consumo extra de desempenho não é muito grande. E diferentes palavras-chave têm consumo diferente, mas algumas têm esse problema e podem ser ignoradas
2. Uma maneira melhor é construir um índice de sobreposição (também conhecido como índice INCLUDE) se as condições permitirem. Premissa: a. O espaço de armazenamento é suficiente, b não afeta significativamente as operações DML, e c não possui campos grandes no índice sobrescrito

CRIE ÍNDICE NÃO AGRUPADO [Ix_index NOME] NO [dbo]. [wkf_ Nome da Mesa]
(
[db_title]  ASC
)
INCLUIR ( [db_id], db_Summary],[db_AddDate])

Neste momento, o plano de consulta de execução é o seguinte, o que é muito mais refrescante

O que foi dito acima é o que consigo pensar agora para processamento SQLSERVER SELECIONE * DO NOME DA TABELA COMO '%Keyword %'