MSSQLSERVER_1205
适用于： 
SQL Server Azure SQL 数据库 Azure SQL 托管实例
详细信息
| Attribute | 值 |
|---|---|
| 产品名称 | SQL Server |
| 事件 ID | 1205 |
| 事件来源 | MSSQLSERVER |
| 组件 | SQLEngine |
| 符号名称 | LK_VICTIM |
| 消息正文 | 事务(进程 ID %d)与另一个进程被死锁在 %.*ls 资源上，并且已被选作死锁牺牲品。 重新运行该事务。 |
说明
在单独的事务上以相互冲突的顺序访问资源，从而导致死锁。 例如：
- Transaction1 更新 Table1.Row1，而 Transaction2 更新 Table2.Row2
- Transaction1 尝试更新 Table2.Row2 ，但已阻止，因为 Transaction2 尚未提交且尚未释放其锁
- Transaction2 现在尝试更新 Table1.Row1 ，但已阻止，因为 Transaction1 尚未提交且未释放其锁
- 之所以出现死锁，是因为 Transaction1 在等待 Transaction2 完成，但 Transaction2 在等待 Transaction1 完成。
系统将检测到此死锁，并选择其中一个涉及的事务作为“牺牲品”。 然后，它将发出此错误消息，回滚该牺牲品的事务。 有关详细信息，请参阅 死锁。
用户操作
在大多数情况下，死锁与应用程序相关的问题需要应用程序开发人员进行代码更改。 收到错误 1205 时，一种方法是再次执行查询。 请参阅此博客，获取有关如何重试的示例 - 处理死锁并重新执行查询： 面向开发人员的死锁模拟器应用：如何在应用中处理 SQL 死锁问题
您还可以修订应用程序以避免死锁。 可以重试被选作牺牲品的事务，而且很可能成功，具体取决于同时执行的操作。
为防止或避免出现死锁，请考虑让所有的事务按相同顺序（先访问 Table1，然后访问 Table2）访问行。 这样，虽然可能会出现阻止，但可避免出现死锁。