Partager via


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 d'arbre B (B-tree) en fonction d'une valeur stockée dans une ligne particulière, le Moteur d'indexation et de recherche en texte intégral crée une structure d'index inversée, empilée, compressée et basée sur des jetons individuels provenant du texte indexé. La taille d’un index de recherche en texte intégral est limitée uniquement par les ressources mémoire dont dispose 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 antérieures de SQL Server. Pour une nouvelle base de données, le catalogue de texte intégral est désormais un objet virtuel qui n'appartient à aucun groupe de fichiers ; il s'agit tout simplement d'un concept logique qui fait référence à un groupe d'index de recherche en texte intégral. Notez toutefois que lors de la mise à niveau d’une base de données SQL Server 2005, tout catalogue de texte intégral contenant des fichiers de données, un groupe de fichiers est créé. Pour plus d’informations, consultez Mettre à niveau Full-Text Rechercher.

Notes

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) peut être indexé pour la recherche en texte intégral. La création d’un index de recherche en texte intégral sur une colonne dont le type de données est varbinary, varbinary(max), imageou xml nécessite que vous spécifiiez 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.

Tâches courantes

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

Pour modifier un index de recherche en texte intégral

Pour supprimer un index de recherche en texte intégral

Dans cette rubrique

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 comme exemple de table. L'extrait suivant montre deux colonnes, la colonne DocumentID et la colonne Title , ainsi que trois lignes provenant de cette table.

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

DocumentID Intitulé
1 Crank Arm and Tire Maintenance
2 Front Reflector Bracket and Reflector Assembly 3
3 Front Reflector Bracket Installation

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

Mot clé ColId DocId Occurrence
Crank 1 1 1
Arm 1 1 2
Tire 1 1 4
Maintenance 1 1 5
Front 1 2 1
Front 1 3 1
Reflector 1 2 2
Reflector 1 2 5
Reflector 1 3 2
Bracket 1 2 3
Bracket 1 3 3
Assembly 1 2 6
3 1 2 7
Installation 1 3 4

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 DocId colonne contient des valeurs pour un entier de huit octets qui correspond à 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 ce cas, les mappages entre les valeurs et les valeurs de clé de DocId texte intégral sont conservés dans une table distincte appelée table 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.

Dans cette rubrique

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éé.

DocumentID Intitulé
3 Rear Reflector

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 la vue de catalogue sys.fulltext_index_fragments .

Fragment 2

Mot clé ColId DocId Occ
Rear 1 3 1
Reflector 1 3 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 à l’aide de 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 :

Mot clé ColId DocId Occ
Crank 1 1 1
Arm 1 1 2
Tire 1 1 4
Maintenance 1 1 5
Front 1 2 1
Rear 1 3 1
Reflector 1 2 2
Reflector 1 2 5
Reflector 1 3 2
Bracket 1 2 3
Assembly 1 2 6
3 1 2 7

Dans cette rubrique