4 Réponses :
En général, vous configurez les index lors de la création de table. Dans cette phase, vous devez déjà avoir une bonne indication de la manière dont vos données seront interrogées et quels champs seront utilisés la plupart des critères de requête.
Lors de la syntonisation des performances, il est généralement recommandé d'avoir les indices évidents en place. Au cours de cette phase, vous serez en mesure de comprendre s'il y a des index qui ne sont pas utilisés efficacement ou s'il existe des requêtes où un index peut augmenter la performance. Rien ne vous empêche de laisser tomber ou d'ajouter de nouveaux index lors du réglage de la performance.
Il y a un équilibre qui doit être frappé. Si vous savez qu'une table sera interrogée et que Fielda fera partie de la clause WHERE et il s'agit d'un champ très sélectionnable (Google Cardinalité), il constitue un bon candidat pour le réglage préventif.
Ne jetez pas index sur toutes sortes de champs car vous pensez que cela a du sens, il faut connaître ces choses. Le réglage prématuré / optimisations sont la racine de tout le mal qu'un homme sage ait dit une fois. Dans ce cas, les indices peuvent nuire aux performances d'insertion / mise à jour car non seulement les données de la table doivent être mises à jour, mais également l'index.
Remarque latérale - Pour certaines grosses charges de données, les personnes abandonnent souvent des index, effectuent la charge, puis recréquez les index de sorte que la charge fonctionne plus rapidement.
En ce qui concerne les avantages et les inconvénients - bien c'est un énorme sujet. Je vous suggère de commencer ici.
J'ajouterais les index "évidents", c'est-à-dire des champs que vous savez être interrogés à la table Create Time, puis ajoutez les autres si nécessaire dans le cadre d'une syntonisation. Il est probablement préférable d'avoir moins d'index au début, puis d'avoir une idée de la performance du système et d'être utilisée - le profil est votre ami entendre.
avantages - un accès plus rapide (lorsque l'indice est utilisé) et la capacité d'appliquer certaines logiques commerciales comme aucun doublage.
Inconvénients - La table prend plus de place, l'insertion de lignes est plus lente (peut être beaucoup plus lente), les mises à jour qui touchent le (s) champ (s) clé (s) sont plus lentes
@Mrtelly Pouvez-vous dire quels sont les index "évidents"?
Comme je l'ai dit, les champs que vous savez seront interrogés également tous les champs de clés étrangers.
Beaucoup (la plupart?) Les DBMS utilisent des index pour prendre en charge des contraintes uniques. Créer toujours des index pour appliquer des contraintes uniques; ils (les contraintes) sont cruciales pour le bon fonctionnement de votre base de données.
où vous avez le choix de créer l'index sur plusieurs colonnes, placez la colonne qui sera toujours référencée dans les requêtes avant d'autres champs - généralement. Ceci est préférable si la colonne principale est également un peu sélective.
Après avoir eu les contraintes nécessaires à l'unicité, considérez celles nécessaires pour appliquer l'intégrité référentielle. Ils sont généralement mandatés par le SGBD. Encore une fois, vous ne pouvez pas vous permettre d'avoir votre base de données dans un état de désintégrité - c'est un système logique, et s'il contient des fausses, vous pouvez prouver tout ce qui n'est plus utile.
Après le caractère unique et les contraintes d'intégrité référentielle sont traitées (indexées), vous pouvez également bénéficier d'autres. Choisissez avec soin et ajoutez aussi peu d'extras que possible (zéro est un bon nombre). Chaque indice ralentit des opérations de mise à jour (mise à jour, insertion, suppression) et utilise l'espace de stockage. L'intention est que cela devrait gagner sa place en accélérant les requêtes. Cependant, n'oubliez pas que l'optimiseur doit penser à chaque index et si elle peut être utile pour répondre à la requête, les index ralentissent également l'optimiseur (bien que vous soyez probablement pressé pour mesurer cet effet).
Lorsque vous ajoutez des index, ajoutez-les sur des colonnes sélectives (pas «sexe» contenant 'm »et' f ', mais peut-être« DOB »contenant des dates de naissance entre 1900 et 2010, ou peut-être encore plus de valeurs distinctes que cela . Considérez si des colonnes supplémentaires vous aideront à répondre à plus de requêtes. Certains SGBD (tels que DB2) prévoient des index avec des colonnes supplémentaires qui ne font pas partie de la contrainte d'unicité, mais qui fournissent des colonnes fréquemment utilisées dans la requête. Celles-ci peuvent permettre à une index. Seulement numériser (un qui n'a pas besoin d'accéder aux données de la table car les valeurs nécessaires sont toutes dans l'index).
Il y a beaucoup plus que cela pourrait être dit, mais cela couvre beaucoup de territoire.
Aussi: Stackoverflow. com / questions / 523018 / ...
Doit lire: sqlskills.com/blogs/kimberly/category/Le -Teme-point.aspx