Une requête update
doit déplacer les entrées
d'index modifiées pour maintenir l'ordre de l'index. Pour cela, la base de
données doit supprimer l'ancienne entrée et ajouter la nouvelle entrée à
la nouvelle position. Le temps de réponse est en gros le même qu'une
requête delete
suivie d'une requête
insert
.
Les performances d'un update
, tout comme un
insert
et un delete
, dépendent aussi
du nombre d'index sur la table. La seule différence est que les requêtes
update
n'affectent pas forcément toutes les colonnes.
Généralement, elles ne modifient que quelques colonnes sélectionnées. En
conséquence, une requête update
n'affecte pas
nécessairement tous les index de la table mais seulement ceux qui
contiennent les colonnes modifiées.
La Figure 8.3 montre le
temps de réponse pour deux requêtes update
: une qui
modifie toutes les colonnes (et donc a un impact sur chaque index) et une
qui met à jour une seule colonne (et du coup a un impact sur un seul
index).
Figure 8.3 Performances de la mise à jour sur les index et le nombre de colonnes

La requête update
sur toutes les colonnes montre
le même motif que celui déjà observé dans les sections précédentes : le temps de réponse
grossit avec chaque nouvel index. Le temps de réponse de la requête
update
qui ne touche qu'un seul index n'augmente pas
tellement car la majorité des index n'est pas à modifier.
Pour optimiser les performances d'un update
, vous
devez faire attention à ne modifier que les colonnes nécessaires. Cela
paraît évident si vous écrivez vous-même la requête
update
. Néanmoins, les outils ORM peuvent générer des
requêtes update
qui modifient toutes les colonnes à
chaque fois. Par exemple, Hibernate le fait si le mode
dynamic-update est désactivé. Depuis la version 4.0, ce mode est activé
par défaut.
Lors de l'utilisation d'outils ORM, une bonne pratique est d'activer de temps en temps la trace des requêtes dans un environnement de développement pour vérifier les requêtes SQL produites. L'encadré « Activer la trace des requêtes SQL » donne un court aperçu sur l'activation des traces des requêtes sur certains outils ORM très utilisés.
Réflexion
Pouvez-vous trouver un exemple où des requêtes
insert
ou delete
n'affectent pas
tous les index d'une table ?