一、背景说明
在业务联调测试或生产验证过程中，经常会遇到 Lock wait timeout 类问题。
业务侧最关心的往往不是“发生了锁冲突”，而是：
究竟是哪一个业务事务、哪一条业务语句，占用了锁资源，导致其他事务超时失败？
在 ZXCLOUD GoldenDB 的分布式架构中，业务 SQL 首先由 CN（计算节点） 接入并进行解析、路由和拆分，最终在多个数据节点上并行执行。
因此，从单一 DB 节点看到的 SQL，往往只是 分布式执行阶段的子语句，并非业务提交的原始 SQL。
本文结合 GoldenDB 的日志体系，介绍一套 从锁超时现象出发，逐层回溯并还原业务真实冲突事务 的实战思路。
二、整体排查思路
锁冲突定位整体可以拆解为四个步骤：
- 从 CN 错误日志中确认锁超时的业务 SQL 及分片信息
- 在对应分片的数据节点上查看锁冲突日志
- 通过锁日志获取冲突双方的线程 ID
- 回到 CN 日志，还原完整业务事务与 SQL 链路
- 核心目标只有一个：
从 DB 层的锁冲突现象，反推出业务真实事务行为
三、数据节点锁冲突日志分析
3.1 锁冲突日志配置
在 GoldenDB 数据节点侧，需要开启锁等待日志，用于记录超过阈值的锁等待与冲突信息。
配置文件路径：
DB 用户 $HOME/etc/my.cnf关键配置项：
innodb_lock_wait_log = on
innodb_lock_wait_timeout = 8参数说明：
- innodb_lock_wait_log：是否开启锁等待日志
- innodb_lock_wait_timeout：锁等待超时时间（单位：秒）
参数支持动态生效，可在问题排查期间临时开启。
3.2 锁冲突日志路径
默认日志路径如下：
DB 用户 $HOME/log/innodb_lock_wait.log该日志专门用于记录 发生锁等待超时的冲突双方事务信息。
3.3 锁冲突日志示例与字段说明
示例日志（节选）：
#WARN: DESC=lock_wait_time:more than 2000ms,
req_thd_id:780442,
req_trx_id:4663955,
req_sql:[SELECT ... FOR UPDATE],
blk_thd_id:450967,
blk_trx_id:4663935,
blk_sql:[SELECT ... FOR UPDATE],
blk_key_data:[1]关键字段说明如下：
- req_thd_id：请求锁的线程 ID
- req_trx_id：请求锁的事务 ID
- req_sql：请求锁时正在执行的 SQL
- blk_thd_id：持有锁、造成阻塞的线程 ID
- blk_trx_id：阻塞事务对应的事务 ID
- blk_sql：阻塞事务当前执行的 SQL
- blk_key_data：被锁住的记录 Key（主键或索引值）
⚠️ 需要注意的是：
锁冲突日志中记录的 SQL，通常是 CN 拆分后下发到数据节点的分布式执行语句，并不一定等同于业务原始 SQL。
因此，仅依靠 DB 锁日志，无法直接定位业务层的事务逻辑。
四、CN 慢日志定位业务 SQL
4.1 CN 慢日志配置
在 CN（计算节点）侧，需要开启慢日志，用于记录业务 SQL 的完整执行过程。
配置文件路径：
CN 用户 $HOME/etc/cn.ini关键参数示例：
slow_query_log = 1
long_query_time = 100参数说明：
- slow_query_log：慢日志开关
- long_query_time：慢 SQL 记录阈值（毫秒）
配置支持动态生效，适合在联调或问题定位期间开启。
4.2 CN 慢日志路径
- 执行成功的慢 SQL：
$HOME/log/slow_query.log- 执行失败的 SQL（如锁超时）：
$HOME/log/slow_errquery.log4.3 通过线程 ID 精确匹配业务 SQL
在数据节点锁冲突日志中，可以拿到关键线索：
- blk_thd_id
- req_thd_id
回到对应 CN 节点，在慢日志中通过 DB connection_id 进行匹配，例如：
DB connection_id:450798通过该 connection_id，可以定位到：
- 对应的业务 SQL
- CN 为该请求分配的全局唯一请求标识（UUID）
五、还原完整业务事务链路
5.1 利用请求 UUID 回溯事务全流程
在 CN 慢日志中，每个业务请求都会携带一个唯一标识，例如：
311-1-9300-1650787948461877使用该 UUID，在 CN 的全量日志中进行反查：
grep '311-1-9300-1650787948461877' general_query.log即可获取该业务事务的完整执行链路，包括：
- 事务内所有 SQL
- SQL 执行顺序
- 是否存在长事务或延迟提交
5.2 常见锁超时根因分析方向
通过还原完整事务后，通常可以快速判断锁超时的根因：
- 事务执行时间过长，迟迟未提交
- 范围更新或删除，锁定记录过多
- 事务内 SQL 顺序不合理
- 业务并发模型与事务设计不匹配
六、总结
在 ZXCLOUD GoldenDB 分布式架构下，锁冲突问题不能只从数据节点视角分析。
一套完整、有效的排查闭环应当是：
CN 错误日志 → 数据节点锁冲突日志 → CN 慢日志 → CN 全量日志
通过 CN 与数据节点日志的联动分析，才能真正定位：
- 哪个业务事务
- 哪些业务 SQL
- 为什么会触发 Lock wait timeout
该方法在业务联调、生产问题定位以及 SQL 与事务设计优化中，均具有很高的实战价值。
