先查innodb_trx中trx_started超1分钟且trx_query为空的长事务，再联查innodb_lock_waits定位blocking_trx_id并kill阻塞源，而非报错事务本身。
查 MySQL 层面的活跃事务和锁等待链
报 Global lock wait timeout 时，Seata 的全局锁（存在 lock_table 表里）只是表象，真正卡住的是底层数据库行锁或间隙锁。必须先确认是不是 MySQL 自身已存在长事务或死锁。
执行以下命令定位阻塞源：
-
SELECT * FROM information_schema.innodb_trx ORDER BY trx_started ASC;—— 找出最早启动却未提交的事务，它极可能是持有锁的“元凶” -
SELECT * FROM information_schema.INNODB_LOCK_WAITS;—— 查看当前锁等待关系，能直接看到哪个线程在等哪个线程的锁 -
SHOW ENGINE INNODB STATUS\G;—— 关键字段是TRANSACTIONS和LATEST DETECTED DEADLOCK，可定位死锁循环
注意：如果 trx_state = RUNNING 且 trx_started 时间远早于当前时间（比如超过 60 秒），基本可以判定该事务异常挂起，需人工干预（KILL 对应 trx_mysql_thread_id）。
确认 Seata 的 lock_table 是否真被占用
Seata 的全局锁由 TC 维护在 lock_table 表中，但这个表本身不加数据库锁；它的“占用”状态实际来自 RM 向 TC 注册分支时对同一资源（如 shop_id=123）的并发注册冲突。所以不能只查表里有没有记录，而要看是否重复注册失败。
检查方式：
- 查
lock_table表：SELECT * FROM lock_table WHERE xid = 'xxx' OR branch_id = xxx;—— 看是否有残留未清理的锁记录（正常情况下回滚或提交后会自动删） - 查 Seata Server 日志关键词：
LockConflict、LockWaitTimeoutException、branch register failed - 确认
seata-server配置中store.mode是db，且store.db.datasource指向的数据库连接正常（常见坑：配置了 db 模式但没建lock_table表，或连接池耗尽）
如果 lock_table 为空但仍有超时，说明问题不在 Seata 锁表本身，而是上游 MySQL 行锁未释放，或者 TC 和 RM 之间网络延迟导致锁注册响应超时。
看 Seata 客户端日志里的 LockRetryController 行为
客户端抛出 Global lock wait timeout 前，会走 LockRetryController.doRetryOnLockConflict，默认重试 30 次，每次间隔 10ms（共 300ms）。这个策略在高并发更新同一行时极易打满重试次数。
关键日志特征：
-
executeAutoCommitTrue error: Global lock wait timeout—— 出现在AbstractDMLBaseExecutor，说明 SQL 执行前卡在锁注册环节 -
Branch register failed for xid=xxx, lockKey=xxx—— 明确指出哪条资源被其他分支抢先锁住 - 连续出现多条相同
lockKey的失败日志 —— 表明多个服务实例在争抢同一业务主键（如shop:123）
此时要检查业务逻辑：是不是把本该串行处理的热点数据（如店铺统计）用并行调用发出去了？AT 模式下，UPDATE shop SET total_sales = ? WHERE id = 123 这类语句天然会成为全局锁瓶颈。
临时绕过与长期规避的实操边界
线上救火时，有人会直接清空 lock_table 或 KILL MySQL 事务，但这有风险：清锁表可能让正在回滚的事务丢失上下文，KILL 可能导致本地事务部分提交。
更稳妥的临时动作：
- 在 Seata Client 端增加
@GlobalTransactional(lockRetryPolicy=LockRetryPolicy.FAST_FAIL)（需 2.1.0+），跳过重试直接失败，避免线程卡死 - 临时调大
client.rm.lock.retry.policy相关参数（如max-retry-times=50），仅限低峰期验证 - 若确定是单点热点，可在业务层加本地锁（如
ConcurrentHashMap.computeIfAbsent）或 Redis 分布式锁，把并发更新收口成串行
长期来看，AT 模式不适合高频更新同一行。这类场景要么改用 TCC（显式 Try 阶段预占）、要么拆分资源粒度（如按日期分表统计）、要么接受最终一致性（异步更新 + 对账）—— 技术选型不是贴个注解就完事，得看锁竞争是否已超出 AT 的舒适区。
