谁在和 OGG 抢锁？一次“看不见”的死锁如何被完整还原

在 MySQL 等数据库的日常运维中，死锁问题虽常见，但往往发生在高并发业务写入场景。然而，当客户反馈 “Oracle GoldenGate（OGG）同步任务频繁因死锁失败” 时，我们不禁产生一个疑问：

OGG 只是单向写入报表库，怎么会和其他事务抢锁，甚至形成死锁？

这听起来几乎不可思议——OGG 同步通常是批量插入，不涉及复杂业务逻辑，更不会主动加锁竞争。那么，到底是谁在和 OGG “抢”同一把锁？

01 用户的困惑——“我的 OGG 到底和谁死锁了？”

用户介绍了死锁产生的大体场景，在使用OGG从实时Oracle库往MySQL报表库同步数据时，频繁遇到死锁错误，导致数据同步任务频繁失败。

Database error 1213([SQL error 1213] Deadlock found when trying to get Lock;try restarting transtation).

更令人头疼的是：

• 客户反复检查所有业务代码，却找不到任何与 OGG 写入表相关的更新或删除操作；
• 死锁日志里确实有两条 SQL，一条来自 OGG（INSERT INTO ...），另一条形如 INSERT INTO batch_value_h SELECT ... FROM ... INNER JOIN ...，但这条 SQL 在应用代码中完全“查无此句”。

问题卡在了最基础的一环：死锁的另一方，究竟是谁？

02 我们产品的锁透视功能——1张泳道图，揭开“隐身”事务的真面目

面对传统死锁日志仅提供孤立 SQL 和模糊事务 ID 的碎片化信息，我们推荐用户使用 DBdoctor的 锁透视功能。

这一能力的背后，创新性地基于 eBPF技术，在内核层无侵入地实时捕获 MySQL 的锁事件、事务生命周期与完整 SQL 执行流。通过 eBPF，DBdoctor 能够：

• 精确追踪每个事务从开启、执行 SQL、申请/等待锁，到提交或回滚的全过程；
• 捕获包括行锁、间隙锁（Gap Lock）、插入意向锁等在内的细粒度锁行为；
• 将分散的锁事件与原始 SQL 语句、上下文进行毫秒级对齐与串联。

基于这些高保真数据，DBdoctor 自动生成直观的 死锁事务泳道图，不仅呈现“谁和谁死锁了”，更还原出“整个冲突是如何一步步演进而成的”。

图片

在这张图中，真相浮出水面：

• 事务 B：正是 OGG 的批量 INSERT 同步任务；
• 事务 A：执行了一条复杂的 INSERT ... SELECT ... JOIN 语句，恰好与 OGG 写入的表存在索引重叠，触发了间隙锁（Gap Lock）竞争；
• 更关键的是——这条 SQL 并非来自应用代码，而是由一个定时 Event 触发的存储过程自动执行！

正是因为这条 SQL 藏身于数据库内部的存储过程，客户才在代码层面“大海捞针”却一无所获。

DBdoctor 不仅定位了死锁 SQL，还完整还原了调用链：Event → 存储过程 → 问题 SQL，让“隐形凶手”无处遁形。

03 从根源优化——降级隔离级别，釜底抽薪解决死锁

图片

进一步分析锁的对象发现，死锁的根源在于 RR（可重复读）隔离级别下的 Gap Lock 机制。在 RR 下，INSERT ... SELECT 会加间隙锁以防止幻读，而 OGG 的批量插入同样会触发行锁与间隙锁，两者在高并发下极易形成循环等待。

鉴于该数据库主要用于 BI 报表场景——对数据强一致性容忍度高，但对系统吞吐与稳定性极为敏感，加之用户回溯发现上次 MySQL 版本升级时未显式配置隔离级别（默认为 RR），我们在与用户协商后：

将隔离级别从 RR 调整为 RC（读已提交）

在 RC 模式下：

• 不再使用 Gap Lock（除非显式使用唯一索引等值查询）；
• 事务持有锁的时间大幅缩短；
• 并发写入冲突显著减少。

调整后，死锁频率下降超过 95%，OGG 同步任务恢复稳定运行。

图片

04 结语：死锁不可怕，可怕的是“看不见”

这次案例的独特之处在于：

• 死锁一方是同步工具 OGG，打破了“死锁必有双向写竞争”的惯性认知；
• 另一方藏身于数据库内部的 Event + 存储过程，脱离了常规代码审查范围。

传统排查手段在此失效，而 这个工具的锁透视功能，凭借事务泳道图首次让这类“幽灵死锁”变得可视、可溯、可解！

当死锁不再是一堆孤立的 SQL，而是一段清晰的业务执行流——问题的解决，也就水到渠成了。