TiDB 6.5 版本遇到 Error 9002 事务锁等待超时怎么解决?

文章导读
TiDB 6.5 报错 Error 9002 表示事务等待锁超时,直接解决办法是查询 information_schema.data_lock_waits 定位持有锁的事务 ID,随后终止阻塞会话或优化长事务。适用场景为业务高峰期锁竞争,风险边界在于终止事务可能引发应用层回滚重试。
📋 目录
  1. 命令速用版
  2. 为什么会这样
  3. 分步处理
  4. 怎么验证是否生效
  5. 常见坑
  6. 常见问题
  7. 参考来源
A A

TiDB 6.5 报错 Error 9002 表示事务等待锁超时,直接解决办法是查询 information_schema.data_lock_waits 定位持有锁的事务 ID,随后终止阻塞会话或优化长事务。适用场景为业务高峰期锁竞争,风险边界在于终止事务可能引发应用层回滚重试。

先说结论:Error 9002 是事务锁等待超时错误,核心处理逻辑是找到持有锁的阻塞会话并解除阻塞。

  • 先确认:查询系统表 information_schema.data_lock_waits 锁定等待关系
  • 先处理:根据事务 ID 终止阻塞会话或优化长事务 SQL
  • 再验证:观察业务错误日志及集群锁等待监控指标

命令速用版

以下命令可直接在 TiDB 客户端执行,用于快速定位锁等待源头。

-- 查看当前锁等待情况
SELECT * FROM information_schema.data_lock_waits LIMIT 10;

-- 查看阻塞他人的事务详情
SELECT * FROM information_schema.cluster_processlist WHERE ID = (SELECT BLOCKING_THREAD_ID FROM information_schema.data_lock_waits LIMIT 1);

-- 终止阻塞会话(需确认业务影响)
KILL TIDB <blocking_thread_id>;

为什么会这样

Error 9002 产生的根本原因是当前事务等待锁的时间超过了变量 tidb_lock_wait_timeout 设定的阈值。

在 TiDB 6.5 版本中,事务采用乐观锁或悲观锁机制,当多个事务竞争同一行数据或热点行时,后发起的事务会进入等待状态。如果持有锁的事务执行时间过长(如大事务、慢 SQL、未提交事务),等待方就会抛出该错误。常见场景包括批量更新未分批、热点行更新竞争、或事务内包含非数据库耗时操作。

分步处理

按照以下步骤排查和处理锁等待超时问题,每一步都需确认操作结果。

步骤 1:查询锁等待视图

执行查询 information_schema.data_lock_waits 表,获取当前正在等待锁的事务及其阻塞者 ID。

SELECT * FROM information_schema.data_lock_waits WHERE KEY_INDEX = 'PRIMARY';

检查点:如果结果为空,说明当前没有锁等待,错误可能是历史遗留或瞬间爆发,需结合日志时间戳排查。

TiDB 6.5 版本遇到 Error 9002 事务锁等待超时怎么解决?

步骤 2:定位阻塞会话

使用上一步查到的 BLOCKING_THREAD_ID,在 cluster_processlist 表中查找对应的会话信息。

SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.cluster_processlist WHERE ID = <BLOCKING_THREAD_ID>;

检查点:观察 INFO 字段显示的 SQL 语句,判断是否为长时间运行的更新或删除操作。

步骤 3:处理阻塞源

如果确认阻塞会话为异常长事务,可执行 KILL TIDB 命令终止会话。

KILL TIDB <BLOCKING_THREAD_ID>;

风险边界:终止会话会导致该事务回滚,可能影响关联业务逻辑,操作前需评估业务容忍度。如果是正常业务长事务,应联系开发人员优化 SQL 或拆分事务。

怎么验证是否生效

处理完成后,通过以下方式确认锁等待问题是否缓解。

1. 查询 data_lock_waits 表,确认等待记录是否消失或减少。

TiDB 6.5 版本遇到 Error 9002 事务锁等待超时怎么解决?

2. 查看应用端错误日志,确认 Error 9002 报错频率是否下降。

3. 在 TiDB 监控面板(如 Grafana)中观察 Transaction Lock Wait Duration 指标,确认峰值是否回落。

常见坑

1. 盲目调大超时时间:修改 tidb_lock_wait_timeout 默认值通常不能解决根本问题,反而可能掩盖长事务风险,导致积压更严重。

2. 忽略 DDL 锁:部分 Error 9002 可能由 DDL 操作引起,需检查 ADMIN SHOW DDL JOBS 确认是否有未完成的 DDL 任务阻塞。

3. 误杀正常会话:在高峰期执行 KILL 命令前,务必确认 COMMAND 状态和 TIME 时长,避免中断正常的关键业务事务。

常见问题

可以直接调大 tidb_lock_wait_timeout 吗?

不建议作为首选方案。调大超时时间只能延缓报错,不能解决锁竞争根本原因,且可能导致事务积压更严重。

Error 9002 是硬件性能不足导致的吗?

通常不是。该错误主要源于事务逻辑设计或锁竞争,而非 CPU 或内存不足,优化重点应在 SQL 和事务粒度。

如何预防未来再次出现?

建议将大事务拆分为小批次提交,避免热点行高频更新,并在代码层设置合理的事务超时重试机制。

参考来源

  • PingCAP 官方文档 - 错误码说明:https://docs.pingcap.com/tidb/stable/error-codes
  • PingCAP 官方文档 - 锁冲突排查:https://docs.pingcap.com/tidb/stable/troubleshoot-lock-conflicts
  • PingCAP 官方文档 - 系统表 data_lock_waits: https://docs.pingcap.com/tidb/stable/information-schema-data-lock-waits