Effet d'un index sur les instructions de mise à jour lorsque la colonne de mise à jour n'est pas dans un index
Je vois constamment des gens dire que les index ralentissent update, delete et insert. Ceci est utilisé comme une instruction générale, comme s'il s'agissait d'un absolu.
Tout en ajustant ma base de données pour améliorer les performances, je continue de rencontrer cette situation qui semble contredire logiquement cette règle pour moi, et nulle part je ne peux trouver quelqu'un dire ou expliquer de quelque manière que ce soit autrement.
Dans SQL Server, et je pense/présume la plupart des autres SGBD, vos index sont créés en fonction des colonnes spécifiques que vous spécifiez. Les insertions et les suppressions affecteront toujours une ligne entière, il n'y a donc aucun moyen qu'elles n'affectent pas l'index, mais les mises à jour semblent un peu plus uniques, elles peuvent spécifiquement affecter uniquement certaines colonnes.
Si j'ai des colonnes qui ne sont incluses dans aucun index et que je les mets à jour, sont-elles ralenties simplement parce que j'ai un index sur d'autres colonnes de cette table?
Par exemple, disons dans ma table User que j'ai un ou deux index, la clé primaire qui est une colonne Identity/Auto Increment, et éventuellement une autre sur une colonne de clé étrangère.
Si je mets à jour une colonne sans l'index directement dessus, comme par exemple leur numéro de téléphone ou leur adresse, cette mise à jour est-elle ralentie parce que j'ai des index sur cette table sur d'autres colonnes dans les deux situations? Les colonnes que je mets à jour ne sont pas dans des index, donc logiquement, les index ne devraient pas être mis à jour, n'est-ce pas? Si quoi que ce soit, je pense qu'ils sont accélérés si j'utilise les index de la clause WHERE.
Vous avez raison, la mise à jour d'une colonne non indexée n'entraînera pas de modifications des index. Dans un cas simple, il n'y aurait pas non plus d'impact global sur la table.
Si une requête peut utiliser l'index pour rechercher des données, cela peut accélérer la recherche, mais le comportement exact (selon votre marque SQL) peut différer des autres marques de SQL. (J'utilise principalement Microsoft SQL Server.)
Bien sûr, la mise à jour d'une colonne avec un volume de données significativement plus important peut entraîner un déplacement des lignes vers différentes pages, et ainsi de suite.
Pour un système moderne relativement rapide, l'ajout d'un seul index à une table OLTP sera probablement pratiquement indétectable du point de vue des performances pour la grande majorité des systèmes. Cela dit , vous ne devez pas créer d'index inutiles et vous ne devez probablement pas créer d'index à colonne unique pour chaque colonne d'une table.
Vous avez raison de supposer que pour de nombreuses requêtes, la présence d'index utiles entraînera une amélioration très sensible de la vitesse.
Bien que votre question semble concerner les performances, il existe plusieurs autres problèmes potentiels liés à l'ajout d'index, notamment, mais sans s'y limiter:
Le temps requis pour créer l'index peut entraîner un blocage pendant que l'index est ajouté à la table. La serrure est de courte durée et ne créera probablement pas de gros problème.
Les modifications d'index entraînent l'annulation des plans d'exécution pour tous les plans faisant référence à la table sous-jacente. Lorsque ces plans d'exécution sont recompilés, les performances peuvent changer négativement pour certaines requêtes.
Les modifications d'index peuvent entraîner des requêtes renvoyant des erreurs là où aucune n'a été précédemment renvoyée. Prenons le cas d'un index filtré qui a été utilisé pour renvoyer des dates contenues dans un champ varchar; si le filtre a supprimé toutes les lignes qui n'étaient pas des dates et que ce filtre a été modifié par la suite, les requêtes qui s'appuyaient sur cet index peuvent désormais échouer lors de la tentative de conversion de données non datées.
Un nouvel index peut entraîner un changement de l'ordre d'exécution, entraînant des blocages possibles survenant là où ils ne s'étaient pas produits auparavant.