Pourquoi des failles d'identité SQL Server apparaissent-elles après l'annulation de transactions ?

Failles d'identité SQL Server : comprendre les impacts des restaurations

Des lacunes inattendues dans les séquences d'identité (auto-incrémentation) de SQL Server peuvent apparaître après des annulations de transactions, en particulier lorsqu'il s'agit d'insertions. Ce n'est pas un bug ; c'est un choix de conception privilégiant la performance.

Considérons un scénario : une transaction .NET s'insère dans une table SQL Server 2005 avec une clé primaire d'identité. Si une erreur déclenche un Rollback(), les lignes insérées sont supprimées. Cependant, la valeur d'identité est déjà incrémentée, laissant un vide.

Ce comportement non transactionnel évite les goulots d'étranglement en matière de performances. Imaginez deux transactions simultanées utilisant un identifiant à numérotation automatique dans le tableau A :

• Transaction 1 : Insère dans les tables A, B, C et D, puis valide.
• Transaction 2 : Insère dans les tables A et B, puis valide.

Si la transaction 2 démarre après la transaction 1, elle devra attendre la fin de la transaction 1 pour obtenir le prochain numéro automatique pour la table A. L'approche non transactionnelle évite ce blocage.

Par conséquent, si des valeurs d'identité strictement séquentielles sont cruciales, des méthodes alternatives sont recommandées. La conception du système donne la priorité à la concurrence plutôt qu'à une numérotation séquentielle stricte.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!