Bei einer update-Anweisung müssen die geänderten Indexeinträge neu einsortiert werden. Dafür werden die alten Daten aus dem Index gelöscht und die neuen, an anderer Stelle, eingefügt. Grundsätzlich summieren sich also die Antwortzeiten der delete- und insert-Anweisungen.
Daher ist die update-Performance ebenfalls von der Anzahl der betroffenen Indizes abhängig. Während insert- und delete-Anweisungen aber immer vollständige Zeilen betreffen, aktualisiert eine update-Anweisung meist nur wenige Spalten. Sie betrifft also nicht automatisch alle Indizes der Tabelle, sondern nur jene, die aktualisierte Spalten beinhalten.
In Abbildung 8.3 ist die Antwortzeit daher für zwei update-Anweisungen dargestellt. Ein update, das alle Spalten und damit alle Indizes betrifft, und ein zweites, das lediglich eine Spalte aktualisiert, die nur in einem Index ist.
Abbildung 8.3 Update-Skalierung über Indexanzahl
Bei dem update auf alle Spalten zeigt sich das bekannte Muster aus den vorherigen Abschnitten: Die Antwortzeit steigt mit jedem zusätzlichen Index. Bei dem update, das nur einen Index betrifft, steigt die Antwortzeit aber nicht so weit, da nur ein Index aktualisiert werden muss.
Zur Optimierung der update-Performance muss man daher darauf achten, nur die tatsächlich geänderten Spalten zu aktualisieren. Das ist auch naheliegend, wenn man die SQL-Anweisungen manuell erstellt. ORM-Werkzeuge können aber durchaus update-Anweisungen generieren, die immer alle Spalten aktualisieren. Bei Hibernate ist das zum Beispiel der Fall, wenn der Dynamic-Update-Modus deaktiviert ist. Seit Version 4.0 ist dieser Modus aber standardmäßig aktiviert.
Bei ORM-Tools ist es generell eine gute Praxis, das SQL-Logging in der Entwicklungsumgebung gelegentlich zu aktivieren und die erstellten Anweisungen zu kontrollieren. „Tipp: SQL-Logging aktivieren“ hat eine kurze Übersicht, wie man das SQL-Logging in gängigen ORM-Tools aktiviert.
Denksport
Gibt es auch Fälle, in denen insert- oder delete-Anweisungen nicht alle Indizes der Tabelle betreffen?
