使用EF6搭配MySQL克隆实体时偶发死锁问题求助

• 事务持有锁时间过长：EF上下文的using块默认会开启隐式事务，你整个读、执行UPDATE、新增、保存的操作都在同一个事务中。默认隔离级别（读提交）下，读操作申请的共享（S）锁会直到事务提交/回滚才释放，而非读完就释放。
• 锁冲突条件命中：你后续执行的同表UPDATE操作需要申请排他（X）锁，高并发场景下，会出现两个事务都持有某行/表的S锁，同时等待对方释放S锁来获取X锁的环形等待条件，就会触发死锁。你封装成统一方法后调用频率更高、执行时序更固定，反而更容易复现死锁。
• 多余读操作放大锁风险：db.Entry(...).GetDatabaseValues().ToObject()的写法会额外触发一次数据库查询，等于在事务内做了两次读操作，进一步拉长了锁持有时间，提升了冲突概率。

• 优先开启数据库读已提交快照隔离（RCSI）：SQL Server等主流数据库都支持该特性，开启后读操作会基于行版本读取，不会申请S锁，从根源上避免读写锁冲突，对于你“实体几乎不会修改”的业务场景完全适配，不需要修改业务代码。
• 优化读操作写法：去掉多余的GetDatabaseValues调用，直接用无跟踪查询读取克隆源，减少查询次数：

var source = db.DBTable.AsNoTracking().Single(x => x.id == id);
var newObject = new DBTable
{
    // 按需复制source的字段，也可以用AutoMapper等对象映射工具批量复制
    id_foreign_key = id_foreign_key,
    used = 1
};

• 优化UPDATE语句：必须为UPDATE增加精准的WHERE过滤条件，避免全表扫描触发表级锁，同时改用参数化查询而非字符串拼接，避免SQL注入风险。
• 缩短事务持有时间：将事务内不需要的逻辑（如参数计算、非数据库操作）移到using块外，尽可能缩短锁的持有时间。

内容的提问来源于stack exchange，提问作者Míra Kníra Němec