Entity Framework关联查询触发Persons表页锁导致死锁问题咨询

• 外键缺失有效索引：Persons表中关联Dossier的外键字段（通常为DossierId）如果没有建立非聚集索引，SQL查询对应Dossier的Persons记录时无法精准定位行，只能扫描聚簇索引的连续数据页，扫描过程中会直接对访问到的页加页锁，不会单独加行锁。
• 锁升级触发：虽然单Dossier关联的Person记录只有10条，但如果高并发下单个事务内涉及的锁数量累计超过阈值（SQL Server默认行锁累计超过5000触发升级），或者数据库内存压力较大时，SQL会自动将零散的行锁合并为页锁/表锁减少锁开销。
• 事务隔离级别过高：如果你的数据库或EF上下文配置的隔离级别高于默认的读提交（比如可重复读、可序列化），共享锁的持有时间会被拉长，也会提升锁升级的概率。

按优先级从高到低排序：

1. 给Persons表外键加禁用页锁的索引（首推，成本最低效果最好）
   为Persons表的Dossier外键创建非聚集索引，同时禁用该索引的页锁权限，强制查询时使用行锁，从根源避免跨Dossier的锁冲突：

   CREATE NONCLUSTERED INDEX IX_Persons_DossierId 
   ON Persons (DossierId)
   WITH (ALLOW_PAGE_LOCKS = OFF);
   

   该索引同时会优化关联查询的性能，不需要额外修改业务代码。
2. 开启读提交快照隔离级别（RCSI）
   在数据库层面开启RCSI，用行版本机制代替读操作的共享锁，读数据完全不加锁，不会和写操作产生锁冲突，也不需要修改业务代码：

   ALTER DATABASE 你的数据库名 SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;
   

   注意执行前需要确保没有活跃事务，建议业务低峰期操作。
3. 缩小事务范围
   检查你的业务代码，不要把整个查询+更新逻辑都包在长事务中，尽量只在调用SaveChangesAsync的阶段开启短事务，减少锁的持有时间，降低冲突概率。
4. 不推荐的方案：
   不要全局关闭数据库锁升级，会导致行锁数量暴增，大幅提升内存开销。只有上述方案都无法解决问题时，才考虑单独为Persons表关闭锁升级：

   ALTER TABLE Persons SET (LOCK_ESCALATION = DISABLE);
   

内容的提问来源于stack exchange，提问作者Nick V