bonjour,
dans l'absolu une réponse rapide consisterait à dire: "je connais les requetes qui sont executées, donc les champs qui sont impliqués dans des jointures donc oui ils sont de bons candidats à l'indexation".
toutefois la question de départ est de définir l'usage auquel est destiné la base de données. En effet pour une base transactionnelle, la problématique sera différente de celle dédiée à un usage décisionnel.
Typiquement dans une base transactionnelle les index pénalisent les requêtes en mise en à jour (insert, update, delete).
Dans une base transactionnelle les requêtes sont gloablement maitrisées et on arrive souvent à optimiser la stratégie d'indexation.
Etant sur le site du LabDecisionnel, je vais partir du principe qu'il s'agit d'une base .... décisionnelle (trop fort !)
Sur l'aspect mise à jour des données la problématique ne se pose pas directement dans une base décisionnelle puisqu'à part lors de l'alimentation de la base, il n'y a pas de modification du contenu (dans les bases à gros volumes on préférera souvent dropper les index avant l'alimentation puis les reconstruire une fois le traitement terminé). En revanche, les requêtes ne sont pas connues à l'avance car bien souvent interrogées par des outils de requetage qui donnent accès à un grand nombre d'indicateurs et axes d'analyse.
En bref et pour tenter d'apporter des éléments de réponse à ta question : il est toujours risqué d'indexer "à priori" une base décisionnelle tant que l'on a pas une idée relativement précise de la manière dont les données seront interrogées.
Bien entendu il existe des axes d'analyse incontournables comme par exemple l'axe temps sur lequels les utilisateurs vont certainement interagir. Dans ce cas sur des bases de fortes volumétrie on privilégiera le partitionnement consistant à demander au moteur de "tronconner" la table physique en tranche selon des intervalles paramétrables (ex une période année mois YYYYMM)
Pour l'utilisateur cela ne change rien puisqu'il aura toujours l'impression de n'avoir qu'une seule table, c'est le moteur qui se charge d'interroger la(les) bonne(s) partition(s).
En terme d'optimisation, certaines actions doivent systematiquement être mises en oeuvre comme par exemple la collecte des statistiques qui aideront l'optimiseur du SGBD à trouver les chemins d'exécutions les plus performants.
Cette action doit être lancée régulièrement dès lors que la volumétrie de la base évolue.
Pour les requetes trop lentes il faut étudier les plans d'exécution (explain suivi de la requete à analyser et de regarder les chemins d'exécution calculés par le moteur)
Des full scan sur des tables sont souvent signes de mauvaises perfomances mais pas toujours.
L'indexation des petites tables n'apporte souvent rien et peut au contraire être pénalisante, l'indexation de champs à faible cardinalité est également souvent inutile car le moteur passera plus de temps à parcourir l'index et ramener les bonnes lignes que de scanner la table. Les tables systèmes sont une mine d'information concernant la typologie des données stockées (répartition, cardinalité, ...)
Dès qu'un index est ajouté il est important de calculer les statistiques associées afin que le moteur puisse les prendre en compte. Sur les moteurs de base de données de dernière génération ces fonctionnalités sont de mieux en mieux gérées et de façon plus automatique.
Quand on crée un index multi-colonnes il est important de savoir que l'index ne sera pertinent que si à minima la première colonne de l'index est impliquée dans une jointure ou un filtre. A fortiori s'il s'agit de plusieurs colonnes ça sera d'autant plus efficace mais en donnant toujours la priorités aux premières colonnes. Supposons un index sur 3 colonnes C1,C2,C3, si je fais une jointure sur C2 ou pire C3 l'index ne sera pas utilisé. En revanche il peut être utilisé si C1 voire C1 et C2 simultanément entrent dans la jointure.
voilà je m'arrête là pour le moment, le sujet est sans fin et surtout sans réponse universelle qui fonctionne à tous les coups. Seules comptent les bonnes pratiques et un peu d'expérience...
J'espère que tu auras trouvé ici qq réponses à tes questions.
Ajouté aux favoris : 0
