[Communication] Problème d’utilisation des indices lorsque SQLSERVER gère des traits comme ' %keyword %'

Déclaration 1 : Le préfixe de joker de pourcentage de signe de pourcentage fera que les requêtes SQL arrêtent l’index et utilisent à la place un scan complet de tables. Cette affirmation est populaire

La conclusion est erronée

En fait, cette affirmation n’est pas très exacte. Le préfixe joker % rendra la recherche SQL des index extrêmement efficace, mais dans la plupart des cas, elle ira quand même à l’index (aucun index en texte intégral n’est requis, il suffit de construire un index normal).

CRÉER UN INDEX NON REGROUPÉ [NOM Ix_index] SUR [DBO]. [wkf_ Nom de la table]
(
[db_title]  ASC
)

Exécutez dès maintenant

SELECT top 10 [db_id],[db_Summary],[db_AddDate],[db_title] DEPUIS [nom de la bibliothèque]. [dbo]. [wkf_database] où [db_title]comme ' %dba %' ordonne de 1 desc

Le plan de requête est clairement affiché

Avant que la comparaison ne soit indexée :

À titre d’exception, requêtes complexes L’optimiseur de requêtes peut abandonner l’index au profit d’un balayage complet de tables. Ce n’est pas seulement le cas avec LIKE « %mot-clé % », mais aussi lié à la complexité des requêtes

Déclaration 2 : Les préfixes en pourcentage de wildcard feront en sorte que les requêtes SQL s’indexent plutôt que pas d’index

Cette affirmation est très unilatérale, et 99 % de l’indice réduira les IO et améliorera l’efficacité par rapport à l’absence d’indexation, mais l’action de correspondance des clés après la découverte de l’indice est également en partie très influente sur la performance. Comme montré dans les deux figures ci-dessus, si les mots-clés sont facilement associés, le balayage complet du tableau trouve rapidement les données, et l’analyse des indices ne permet pas de gagner assez de temps pour compenser le temps nécessaire à l’action de correspondance des clés (la plupart des requêtes en ligne ne rencontrent pas ce problème).
Traitement :
1. Si cela ne vous intéresse pas, la consommation de performance supplémentaire n’est pas très importante. Et différents mots-clés ont une consommation différente, mais certains mots-clés ont ce problème et peuvent être ignorés
2. Une meilleure méthode consiste à construire un indice de dérogation (également appelé indice INCLUDE) si les conditions le permettent. Prémisse : a. L’espace de stockage est suffisant, b n’affecte pas significativement les opérations DML, et c ne possède pas de champs importants dans l’index écrasé

CRÉER UN INDEX NON REGROUPÉ [NOM Ix_index] SUR [DBO]. [wkf_ Nom de la table]
(
[db_title]  ASC
)
INCLUDE ( [db_id], db_Summary],[db_AddDate])

À ce stade, le plan d’exécution des requêtes est le suivant, ce qui est bien plus rafraîchissant

Ce qui précède est ce à quoi je pense maintenant pour le traitement SQLSERVER SELECT * FROM TABLENAME COMME ' %Keyword %'