Passer au contenu principal
Disponible à partir du plan Business auto-hébergé
Chemin : Administration système → Opérations de requêtes de Table Utilisez Recherche et index de Table lorsque les Vues, filtres, relations ou recherches sur une grande Table deviennent lents. Teable surveille la charge des requêtes en arrière-plan et résume chaque Table : comment elle est recherchée aujourd’hui, quels Champs sont couverts, quels index physiques existent et combien de requêtes lentes ont été observées récemment. Les administrateurs de l’instance configurent ici la couverture de recherche, créent des index et suivent les résultats.
La page met uniquement des tâches en file d’attente, elle ne modifie jamais la base de données directement. Chaque changement s’exécute de façon asynchrone en arrière-plan : vérifiez le résultat sous Tâches / historique.
Les opérations de requêtes de Table sont désactivées par défaut. Définissez V2_TABLE_QUERY_OPS_ENABLED sur true côté backend, puis redémarrez : la page commence alors à collecter des observations.

Trouver la Table à traiter

La page s’ouvre sur la liste des Tables. Les boutons d’état en haut portent leur propre compteur et réduisent la liste : Le champ de recherche accepte les noms ou identifiants de Table, de Projet et d’Espace. Le tri se fait par Plus de requêtes lentes ou par Nom de Table. La Fenêtre d’observation couvre la dernière heure ou 24 heures, et toutes les valeurs d’observation de la liste suivent cette fenêtre. Les observations sont conservées 2 jours ; au-delà, elles n’apparaissent plus dans la liste. Chaque ligne donne le nombre de lignes et la taille estimés de la Table, les requêtes et requêtes lentes de la fenêtre, la méthode de recherche actuelle et la couverture des Champs, le nombre d’index de filtre/tri, ainsi que les recommandations en attente et les tâches actives. Cliquez sur le nom d’une Table pour ouvrir son détail. À côté des boutons d’état, À propos des états d’index explique comment ces compteurs sont calculés.

Lire l’état de l’index

La liste des Tables et le détail affichent l’état de l’index à côté de la méthode de recherche : Deux lignes peuvent apparaître sous l’état. Configuré : pg_bigm / pg_trgm signale que le fournisseur enregistré diffère de la méthode de recherche utilisée, et Commutateur d’exécution de la recherche indexée : désactivé signale que l’index est prêt mais que l’exécution est coupée, la recherche restant en ILIKE. Lorsqu’une notification en haut de la page signale des Tables dont l’index de recherche configuré n’est pas en service, la recherche sur ces Tables retombe sur ILIKE. Si elle indique aussi que le worker de tâches est désactivé, définissez V2_TABLE_QUERY_OPS_TASK_WORKER_ENABLED sur true côté backend, puis redémarrez pour que les index puissent être reconstruits.
Un index publié ne garantit pas que chaque recherche l’utilise : un terme trop court ou un Champ hors couverture retombe sur ILIKE. Cette page indique l’état de l’index, elle ne prouve pas que des requêtes récentes l’ont utilisé.

Configurer la couverture de recherche

L’onglet Couverture de recherche indique la méthode de recherche actuelle de la Table, le nombre de Champs couverts et la Couverture effective de chaque Champ. Afficher les champs non couverts restreint la liste aux Champs pas encore inclus ; les Champs marqués Non éligible ne peuvent pas alimenter un index de recherche par sous-chaîne.
La couverture effective suppose des métadonnées d’index publiées et exploitables ainsi qu’un commutateur d’exécution activé ; une configuration enregistrée seule ne compte pas. La couverture est explicite : les Champs ajoutés ensuite ne sont pas inclus automatiquement, reconfigurez la Table pour les intégrer.
Choisissez Configurer la recherche sur une Table jamais configurée, ou Mettre à jour la sélection / reconstruire sur une Table déjà configurée, qui s’ouvre avec le fournisseur et la sélection de Champs enregistrés la fois précédente. La boîte de dialogue demande : Analyser et simuler exécute la modification sans la valider et rend le nombre de Champs couverts, le nombre de lignes estimé, la présence d’éléments de plan et l’impact d’une création ou d’une reconstruction. Les Tables estimées à 50 000 lignes ou plus, ainsi que celles de taille inconnue, exigent en plus la confirmation de la fenêtre de maintenance. Choisissez ensuite Confirmer et mettre la tâche en file d’attente.
Créer ou reconstruire la couverture de recherche génère une colonne de recherche et un index GIN. L’opération peut réécrire toute la Table, poser des verrous et interrompre brièvement la recherche indexée. Planifiez-la pendant une fenêtre de maintenance.
La boîte de dialogue renvoie un accusé de réception de tâche, pas un résultat. Fermez-la et suivez la tâche sous Tâches / historique. Soumettre à nouveau la même modification renvoie la tâche existante.

Gérer les index de filtre et de tri

L’onglet Index de filtre / tri répertorie les index physiques qui servent les conditions de filtre et les tris de cette Table, chacun avec sa validité, l’indication de gestion par Teable, sa taille et sa définition. Ils sont gérés séparément des index de recherche par sous-chaîne. En dessous, les Actions en attente regroupent les recommandations d’index du système et précisent si des éléments de plan les étayent. Examiner la création d’index montre l’index proposé, la base de données d’exécution et les éléments probants ; après votre confirmation, Teable exécute CREATE INDEX CONCURRENTLY de façon asynchrone. Les grandes Tables et celles de taille inconnue exigent ici aussi la confirmation de la fenêtre de maintenance.
Cette page ne supprime pas d’index. Les index non gérés et les index système peuvent protéger des contraintes ou servir d’autres charges de travail ; ils ne sont pas touchés.

Diagnostiquer des requêtes précises

Lorsqu’une Table est signalée comme lente sans recommandation associée, ouvrez l’onglet Diagnostic des requêtes et choisissez Analyser les requêtes. L’analyse lit uniquement les formes de requêtes enregistrées et les éléments de plan disponibles ; elle ne crée rien. La conclusion est Opportunités d’index étayées par un plan trouvées, Aucune opportunité d’index confirmée par les plans disponibles ou Éléments insuffisants. Des éléments insuffisants ne signifient pas qu’un balayage séquentiel a eu lieu : une observation lente ne prouve pas à elle seule que le chemin d’accès est en cause. En dessous figure chaque requête concernée, avec l’origine (trafic réel ou configuration de Vue enregistrée) et le coût de plan estimé avant et après l’index proposé (coût de plan, pas des millisecondes).

Suivre les résultats

L’onglet Tâches / historique comporte trois parties :
  • Tâches : les tâches d’arrière-plan de cette Table, avec statut, nombre de tentatives, type de tâche et cause de l’échec. Lorsqu’une tâche a fini par réussir après un échec, l’erreur est signalée comme une tentative antérieure.
  • Historique de configuration de recherche : le fournisseur, le statut et la liste des Champs de chaque configuration de couverture passée.
  • Historique des recommandations : les recommandations acceptées, écartées ou remplacées.
L’historique ne charge que les entrées les plus récentes. S’il y en a davantage, une ligne au-dessus de la liste en donne le total.
Tant qu’une tâche est en file d’attente ou en cours sur une Table, les boutons de configuration de la recherche et de création d’index restent désactivés. Attendez la fin de la tâche.
Dernière modification le 14 octobre 2026