Quand devriez-vous utiliser l’indexation de texte intégral ?

Question

Nous avons tout un tas de requêtes qui « recherchent » des clients, des clients, etc.Vous pouvez effectuer une recherche par prénom, email, etc.Nous utilisons les instructions LIKE de la manière suivante :

SELECT * 
FROM customer 
WHERE fname LIKE '%someName%'

L'indexation en texte intégral est-elle utile dans le scénario ?Nous utilisons SQL Server 2005.

Answer 1

Cela dépendra de votre SGBD.Je pense que la plupart des systèmes ne profiteront pas de l'index de texte intégral à moins que vous n'utilisiez les fonctions de texte intégral.(par exemple. MATCH CONTRE en mySQL ou FREETEXT/CONTAINS en MS SQL)

Voici un bon article expliquant quand, pourquoi et comment utiliser l'indexation de texte intégral dans SQL Server : Comprendre l'indexation de texte intégral SQL Server

Answer 2

Service fédéral des impôts peut aider dans ce scénario, la question est de savoir si cela en vaut la peine ou non.

Pour commencer, voyons pourquoi LIKE n'est peut-être pas la recherche la plus efficace.Quand vous utilisez LIKE, surtout lorsque vous effectuez une recherche avec un % au début de votre comparaison, SQL Server doit effectuer à la fois une analyse de table de chaque ligne et une vérification octet par octet de la colonne que vous vérifiez.

FTS dispose de meilleurs algorithmes pour faire correspondre les données, ainsi que de meilleures statistiques sur les variations de noms.Par conséquent, FTS peut fournir de meilleures performances pour faire correspondre Smith, Smythe, Smithers, etc. lorsque vous recherchez Smith.

Il est cependant un peu plus complexe d'utiliser FTS, car il faut maîtriser CONTAINS contre FREETEXT et le format mystérieux de la recherche.Cependant, si vous souhaitez effectuer une recherche dans laquelle FName ou LName correspondent, vous pouvez le faire avec une seule instruction au lieu d'un OR.

Pour déterminer si FTS sera efficace, déterminez la quantité de données dont vous disposez.J'utilise FTS sur une base de données de plusieurs centaines de millions de lignes et c'est un réel avantage par rapport à la recherche avec LIKE, mais je ne l'utilise pas sur toutes les tables.

Si la taille de votre table est plus raisonnable, inférieure à quelques millions, vous pouvez obtenir une vitesse similaire en créant un index pour chaque colonne sur laquelle vous allez effectuer la recherche et SQL Server doit effectuer une analyse d'index plutôt qu'une analyse de table.

Answer 3

D'après mon scénario de test :

• SQL Serveur 2008
• 10.000.000 lignes chacune avec une chaîne comme "worda wordb wordc ..." (varie entre 1 et 30 mots)
• en sélectionnant count(*) avec CONTAINS(column, "wordB")
• taille du résultat plusieurs centaines de milliers
• taille du catalogue environ 1,8 Go

L'index de texte intégral était compris entre 2 et 2 s. comme '% motB %' était à portée de 1 à 2 minutes.

Mais cela ne compte que si vous n'utilisez aucun critère de sélection supplémentaire ! Par exemple.si j'en ai utilisé "comme 'préfixe%'" sur une colonne de clé primaire de plus, les performances étaient moins bonnes puisque l'opération d'accès à l'index de texte intégral coûte plus cher que de faire une recherche de chaîne dans certains champs (à condition que ce ne soit pas trop).

Je recommanderais donc un index en texte intégral seulement dans les cas où vous devez effectuer une "recherche de chaîne gratuite" ou utiliser certaines de ses fonctionnalités spéciales...

Answer 4

Pour répondre à la question spécifiquement pour MSSQL, l'indexation de texte intégral sera PAS aider dans votre scénario.

Afin d'améliorer cette requête, vous pouvez effectuer l'une des opérations suivantes :

1. Configurez un catalogue de texte intégral sur la colonne et utilisez la fonction CONTAINS().

2. Si vous recherchiez principalement avec un préfixe (c.-à-d.correspondant au début du nom), vous pouvez remplacer le prédicat par le suivant et créer un index sur la colonne.

   où fname ressemble à 'prefix%'

(1) est probablement excessif pour cela, à moins que les performances de la requête ne constituent un gros problème.