Décision quand créer l'index sur la colonne de table dans la base de données?
Je ne suis pas db guy. Mais j'ai besoin de créer des tables et de faire des opérations CRUD dessus. Je suis confus, dois-je créer l'index sur toutes les colonnes par défaut ou non? Voici ma compréhension que je considère lors de la création d'un index.
L'index contient essentiellement la plage d'emplacement de mémoire (à partir de l'emplacement de mémoire où la première valeur est stockée jusqu'à la fin de l'emplacement de mémoire où la dernière valeur est stockée). Ainsi, lorsque nous insérons une valeur dans l'index de la table, la colonne doit être mise à jour car elle a une valeur de plus, mais la mise à jour de la valeur de la colonne n'aura aucun impact sur la valeur de l'index. Droite? Donc, en fin de compte, lorsque ma colonne est utilisée en jointure entre deux tables, nous devrions envisager de créer un index sur la colonne utilisée dans la jointure, mais toutes les autres colonnes peuvent être ignorées car si nous créons un index sur elles, cela impliquera Coût supplémentaire de mise à jour de la valeur d'index lorsqu'une nouvelle valeur est insérée dans la colonne .N'est-ce pas?
Considérez ce scénario où la table mytable contient deux trois colonnes, c'est-à-dire col1, col2, col3. Nous lançons maintenant cette requête
select col1,col2 from mytable
Maintenant, il y a deux cas ici. Dans le premier cas, nous créons l'index sur col1 et col2. Dans le deuxième cas, nous ne créons aucun index. ** Selon ma compréhension, le cas 1 sera plus rapide que le cas 2 car dans le cas 1, nous pouvons trouver rapidement l'emplacement de la mémoire des colonnes. Donc, ici, je n'ai utilisé aucune colonne de jointure, mais l'index aide toujours ici. Alors, dois-je envisager de créer un index ici ou non? **
Et si dans le même scénario ci-dessus si nous tirons
select * from mytable
au lieu de
select col1,col2 from mytable
L'index aidera-t-il ici?
mais la mise à jour de la valeur de colonne n'aura aucun impact sur la valeur d'index. Droite?
Non. La mise à jour d'une colonne indexée aura un impact. Oracle 11g manuel de performance indique que:
Les instructions UPDATE qui modifient les colonnes indexées et les instructions INSERT et DELETE qui modifient les tables indexées prennent plus de temps que s'il n'y avait pas d'index. Ces instructions SQL doivent modifier les données des index et les données des tables. Ils créent également des annulations et des rétablissements supplémentaires.
Donc, en fin de compte, lorsque ma colonne est utilisée en jointure entre deux tables, nous devrions envisager de créer un index sur la colonne utilisée dans la jointure, mais toutes les autres colonnes peuvent être ignorées car si nous créons un index sur elles, cela impliquera un coût supplémentaire de mise à jour de la valeur d'index lors de la nouvelle valeur est inséré dans la colonne. Droite?
Pas seulement des insertions mais toute autre instruction du langage de manipulation de données.
Considérez ce scénario. . . L'index aidera-t-il ici?
En ce qui concerne ce dernier paragraphe, pourquoi ne pas créer des cas de test avec des volumes de données représentatifs afin de prouver ou d'infirmer vos hypothèses sur les colonnes que vous devez indexer?
Ne créez pas d'index dans chaque colonne! Cela ralentira les opérations d'insertion/suppression/mise à jour.
Pour rappel, vous pouvez créer un index dans des colonnes courantes dans WHERE, ORDER BY et GROUP BY clauses. Vous pouvez envisager d'ajouter un index dans des colonnes utilisées pour relier d'autres tables (par le biais d'un JOIN, par exemple)
Exemple:
SELECT col1,col2,col3 FROM my_table WHERE col2=1
Ici, la création d'un index sur col2 aiderait beaucoup cette requête.
Tenez également compte de la sélectivité de l'index. Autrement dit, créez un index sur les valeurs qui ont un "grand domaine", c'est-à-dire les identifiants, les noms, etc. Ne les créez pas sur les colonnes Homme/Femme.
Dans le scénario spécifique que vous donnez, il n'y a pas de clause WHERE, donc une analyse de table va être utilisée ou l'analyse d'index sera utilisée, mais vous ne supprimez qu'une colonne, donc les performances peuvent ne pas être si différentes. Dans le deuxième scénario, l'index ne doit pas être utilisé, car il ne couvre pas et il n'y a pas de clause WHERE. S'il y avait une clause WHERE, l'index pourrait permettre au filtrage de réduire le nombre de lignes à rechercher pour obtenir la colonne manquante.
Oracle a un certain nombre de tables différentes, y compris des tables organisées en tas ou en index.
Si un indice couvre, il est plus susceptible d'être utilisé, surtout lorsqu'il est sélectif. Mais notez qu'une table organisée par index n'est pas meilleure qu'un index de couverture sur un tas lorsqu'il y a des contraintes dans la clause WHERE et beaucoup moins de colonnes dans l'index de couverture que dans la table de base.
La création d'index avec plus de colonnes que ce qui est réellement utilisé n'aide que s'ils sont plus susceptibles de couvrir l'index, mais l'ajout de toutes les colonnes serait similaire à une table organisée par index. Notez qu'Oracle n'a pas l'équivalent de INCLUDE (COLUMN) de SQL Server qui peut être utilisé pour rendre les index plus couvrants (il crée en fait un index clusterisé supplémentaire uniquement d'un sous-ensemble des colonnes - utile si vous voulez qu'un index soit unique mais ajoutez également des données que vous ne souhaitez pas voir prises en compte dans le caractère unique, mais qui contribuent à les couvrir pour plus de requêtes)
Vous devez examiner vos plans et déterminer ensuite si les index vous aideront. Et regardez ensuite les plans pour voir s'ils ont fait une différence.