Créer et gérer des index de recherche en texte intégral

Les informations contenues dans les index de recherche en texte intégral sont utilisées par le Moteur d'indexation et de recherche en texte intégral pour compiler des requêtes de texte intégral qui permettent de rechercher rapidement certains mots ou combinaisons de mots dans une table. Un index de recherche en texte intégral stocke les informations se rapportant aux mots significatifs et à leur emplacement dans une ou plusieurs colonnes d'une table de base de données. Un index de recherche en texte intégral est un type spécial d'index fonctionnel par jeton qui est construit et géré par le Moteur d'indexation et de recherche en texte intégral pour SQL Server. Le processus de création d'un index de texte intégral diffère du processus de création des autres types d'index. Au lieu de construire une structure B-tree selon une valeur stockée dans une ligne particulière, le moteur d'indexation et de recherche en texte intégral génère une structure d'index inversée, empilée et compressée selon des jetons individuels du texte indexé. La taille d'un index de recherche en texte intégral est uniquement limitée par les ressources de mémoire disponibles de l'ordinateur sur lequel l'instance de SQL Server s'exécute.

À compter de SQL Server 2008, les index de recherche en texte intégral sont intégrés au moteur de base de données, au lieu de résider dans le système de fichiers comme dans les versions précédentes de SQL Server. Pour une nouvelle base de données, le catalogue de texte intégral est maintenant un objet virtuel qui n'appartient pas à un groupe de fichiers ; il s'agit simplement d'un concept logique qui fait référence à un groupe d'index de recherche en texte intégral. Notez toutefois que pendant la mise à niveau d'une base de données SQL Server 2005, pour tout catalogue de texte intégral qui contient des fichiers de données, un nouveau groupe de fichiers est créé ; pour plus d'informations, consultez Mettre à niveau la recherche en texte intégral à partir de SQL Server 2005.

[!REMARQUE]

Dans SQL Server 2008 et les versions ultérieures, le moteur d'indexation et de recherche en texte intégral réside dans le processus SQL Server, plutôt que dans un service séparé. L'intégration du Moteur d'indexation et de recherche en texte intégral dans le Moteur de base de données permet une simplification de la gestion de l'indexation et de la recherche en texte intégral, ainsi qu'une amélioration de l'optimisation des requêtes mixtes et des performances globales.

Un seul index de recherche en texte intégral est autorisé par table. Pour qu'un index de recherche en texte intégral puisse être créé sur une table, cette dernière doit posséder une colonne d'index unique, qui n'accepte pas les valeurs Null. Vous pouvez créer un index de recherche en texte intégral sur des colonnes de type char, varchar, nchar, nvarchar, text, ntext, image, xml, varbinary et varbinary(max) qui peuvent être indexées pour la recherche en texte intégral. Lorsque vous créez un index de recherche en texte intégral sur une colonne de type de données varbinary, varbinary(max), image, ou xml, vous devez spécifier une colonne de type. Une colonne de type est une colonne de table dans laquelle vous stockez l'extension de fichier (.doc, .pdf, .xls, etc.) du document dans chaque ligne.

Le processus de création et de gestion d'un index de recherche en texte intégral est appelé alimentation (également appelé analyse). Il existe trois types d'alimentation de l'index de recherche en texte intégral : l'alimentation complète, l'alimentation basée sur le suivi des modifications et l'alimentation incrémentielle basée sur l'horodateur. Pour plus d'informations, consultez Alimenter des index de recherche en texte intégral.

Dans cette rubrique

• Tâches courantes

• Structure d'index de recherche en texte intégral

• Fragments d'index de recherche en texte intégral

Tâches courantes

Pour créer un index de recherche en texte intégral

• CREATE FULLTEXT INDEX (Transact-SQL)

Pour modifier un index de recherche en texte intégral

• ALTER FULLTEXT INDEX (Transact-SQL)

Pour supprimer un index de recherche en texte intégral

• DROP FULLTEXT INDEX (Transact-SQL)

[Haut de la page]

Structure d'index de recherche en texte intégral

La compréhension de la structure d'un index de recherche en texte intégral vous permet de comprendre également le fonctionnement du Moteur d'indexation et de recherche en texte intégral. Cette rubrique utilise l'extrait suivant de la table Document dans Adventure Works en guise de table d'exemples. Cet extrait affiche uniquement deux colonnes, la colonne DocumentID et la colonne Title, ainsi que trois lignes de la table.

Pour cet exemple, il faut partir de l'hypothèse qu'un index de recherche en texte intégral est créé sur la colonne Title.

Par exemple, la table suivante, qui illustre le Fragment 1, décrit le contenu de l'index de recherche en texte intégral créé sur la colonne Title de la table Document. Les index de recherche en texte intégral contiennent plus d'informations que les éléments présentés dans cette table. La table est une représentation logique d'un index de recherche en texte intégral et est fournie à des fins de démonstration uniquement. Les lignes sont stockées dans un format compressé pour optimiser l'utilisation du disque.

Remarquez que les données ont été inversées par rapport aux documents d'origine. L'inversion se produit parce que les mots clés sont mappés aux ID de document. Pour cette raison, un index de recherche en texte intégral est souvent désigné par le nom d'un index inversé.

Remarquez également que le mot clé « and » a été supprimé de l'index de recherche en texte intégral. Cela s'explique du fait que « and » est un mot vide, et que la suppression de mots vides d'un index de recherche en texte intégral peut induire des économies substantielles en termes d'espace disque, d'où une amélioration des performances des requêtes. Pour plus d'informations sur les mots vides, consultez Configurer et gérer les mots vides et listes de mots vides pour la recherche en texte intégral.

Fragment 1

La colonne Keyword contient la représentation d'un jeton unique extrait au moment de l'indexation. Les analyseurs lexicaux déterminent le contenu d'un jeton.

La colonne ColId contient une valeur qui correspond à une colonne particulière indexée en texte intégral.

La colonne DocId contient les valeurs d'un entier sur 8 octets mappé à une valeur de clé de texte intégral particulière dans une table indexée en texte intégral. Ce mappage est nécessaire lorsque la clé de texte intégral n'est pas un type de données integer. Dans de tels cas, les mappages entre les valeurs de clé de texte intégral et les valeurs DocId sont maintenus dans une table séparée appelée la table de mappage DocId. Pour lancer une requête à propos de ces mappages, utilisez la procédure stockée système sp_fulltext_keymapping. Pour satisfaire à un critère de recherche, les valeurs DocId de la table précitée doivent être jointes avec la table de mappage DocId pour extraire des lignes de la table de base qui est interrogée. Lorsque la valeur de clé de texte intégral de la table de base est un type de données Integer, la valeur sert directement de DocId et aucun mappage n'est nécessaire. Par conséquent, l'utilisation de valeurs de clé de texte intégral Integer peut contribuer à optimiser des requêtes de texte intégral.

La colonne Occurrence contient une valeur entière. Pour chaque valeur DocId, il existe une liste de valeurs d'occurrences qui correspondent aux décalages de mots relatifs du mot clé spécifique contenu dans DocId. Les valeurs d'occurrences servent à déterminer les correspondances d'expressions ou de proximité, par exemple lorsque des expressions ont des valeurs d'occurrences adjacentes numériquement. Elles servent également à calculer les scores de pertinence ; par exemple, le nombre d'occurrences d'un mot clé dans DocId peut être utilisé pour l'établissement d'un score.

[Haut de la page]

Fragments d'index de recherche en texte intégral

L'index de recherche en texte intégral logique est habituellement fractionné entre plusieurs tables internes. Chaque table interne est appelé fragment d'index de recherche en texte intégral. Quelques-uns de ces fragments peuvent contenir des données plus récentes que d'autres. Par exemple, si un utilisateur met à jour la ligne suivante dont DocId est 3 et que la table effectue un suivi automatique des modifications, un nouveau fragment est créé.

Dans l'exemple suivant, qui illustre le Fragment 2, le fragment contient des données plus récentes à propos de DocId 3 par rapport à Fragment 1. Par conséquent, lorsque l'utilisateur émet des requêtes concernant « Rear Reflector », les données de Fragment 2 sont utilisées pour DocId 3. Chaque fragment est marqué avec un horodateur de création qui peut être interrogé à l'aide de l'affichage catalogue sys.fulltext_index_fragments.

Fragment 2

Comme on peut le constater d'après Fragment 2, les requêtes de texte intégral doivent interroger chaque fragment en interne et ignorer les entrées plus anciennes. Par conséquent, trop de fragments d'index de recherche en texte intégral dans l'index de texte intégral peut conduire à une dégradation substantielle dans les performances des requêtes. Pour réduire le nombre de fragments, réorganisez le catalogue de texte intégral en utilisant l'option REORGANIZE de l'instruction Transact-SQL ALTER FULLTEXT CATALOG. Cette instruction effectue une fusion principale, c'est-à-dire une fusion de tous les fragments en un fragment unique plus grand et supprime toutes les entrées obsolètes de l'index de recherche en texte intégral.

Une fois réorganisé, l'index de l'exemple contient les lignes suivantes :

[Haut de la page]