La problématique de la modification.

donc dans le même cas que l’insertion. Mais si la clef ou les éventuelles données complémentaires à modifier sont de taille variable et que cette taille est plus grande que la version précédente, alors cela entraîne le déplacement de cette ligne.

En effet, si une ligne d’index ou une ligne de table doit passer d’une taille donnée à une taille plus grande, il n’est plus possible de la stocker à son emplacement originel, car les lignes sont mises bout à bout dans une page. Comme d’un côté il serait trop coûteux de remanier les pages chaque fois qu’un tel UPDATE survient et que l’autre solution conduirait à de nombreuses divisions de pages résultant de l’application d’un split4 et que cela qui conduirait à clairsemer drastiquement l’index, SQL Server a choisi une troisième voie : déporter ces lignes dans de nouvelles pages en fin d’index, tout en indiquant l’indirection dans l’emplacement originel.

Autrement dit, dans un tel cas, SQL Server se sert de l’ancienne entrée d’index pour indiquer que la ligne a été déplacée et reporte les nouvelles valeurs de la ligne dans un espace libre de l’index, c’est à dire, généralement une page supplémentaire. La problématique qui en résulte est une lecture en zigzag. Ainsi, dès que plusieurs lignes de la table ou l’index doivent être lues, chaque ligne déplacée oblige à passer d’une page à l’autre et y revenir pour lire la ligne suivante. A terme, il n’est pas rare de devoir lire huit à dix fois plus de pages que nécessaires !