SQL锁等待过多表现为查询变慢、事务卡住等，需先确认锁等待状态，再定位阻塞会话与持有锁源头，分析锁类型、SQL逻辑及事务设计问题。
SQL 锁等待过多，通常表现为查询变慢、事务卡住、应用响应延迟甚至超时。核心思路是：先确认锁等待是否存在及严重程度，再定位被阻塞的会话和持有锁的源头，最后分析锁类型、SQL逻辑与事务设计问题。
查当前锁等待状态
快速判断是否有活跃的锁等待：
- MySQL：执行 SELECT * FROM information_schema.INNODB_TRX 查看运行中的事务；配合 SELECT * FROM information_schema.INNODB_LOCK_WAITS（5.7+）或 SHOW ENGINE INNODB STATUS\G 中的 LATEST DETECTED DEADLOCK 和 TRANSACTIONS 部分，识别阻塞链
- PostgreSQL：查 pg_stat_activity 过滤
wait_event_type = 'Lock'，再关联 pg_locks 和 pg_stat_activity 找出 blocking_pid - SQL Server：用 sys.dm_exec_requests 查
blocking_session_id > 0的会话，再通过 sys.dm_tran_locks 关联资源锁定详情
定位阻塞源头 SQL 和事务
仅知道“谁在等”不够，必须找到“谁在占着不放”：
- 检查持有锁的会话是否执行了未提交的 DML（如 UPDATE/DELETE 无 WHERE 或未 COMMIT）
- 查看该会话的 trx_started（MySQL）或 backend_start / xact_start（PG/SQL Server），判断事务是否异常长
- 用 SHOW FULL PROCESSLIST（MySQL）、SELECT query FROM pg_stat_activity WHERE pid = ?（PG）或 DBCC INPUTBUFFER(?))（SQL Server）还原被阻塞方和阻塞方的实际 SQL
- 注意隐式事务：某些 ORM 或客户端设置 autocommit=off 后，单条语句也会开启长事务
分析锁粒度与隔离级别影响
不是所有锁都该被消灭，但需确认是否合理：
- RR（可重复读）下范围锁（gap lock）可能造成意外阻塞，尤其在非唯一索引条件更新时；尝试用唯一索引或降低隔离级别到 RC（读已提交）验证
- UPDATE/DELETE 若未走索引，会升级为表锁或大量行锁，检查 EXPLAIN 结果，补上缺失索引
- 高并发场景下，自增主键插入一般不锁表，但批量 INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE 可能引发间隙锁争用
- 避免在事务中混用 SELECT FOR UPDATE 和普通 SELECT，尤其跨多个表时容易形成锁循环
从应用层收敛常见诱因
很多锁等待本质是业务逻辑或调用方式导致：
- 事务里做 HTTP 请求、文件读写、复杂计算——这些耗时操作让锁持有时间大幅延长
- 重试逻辑不当：失败后未回滚就重试，导致同一行被多次加锁
- 批量操作未分页：一次更新 10 万行 → 持锁时间长 + 日志暴涨 → 建议按主键分片，每次 1000 行内提交
- 缓存与 DB 不一致时，频繁“先查再更”模式易产生竞争，考虑改用原子操作（如 UPDATE ... SET count = count + 1）或乐观锁
锁等待不是故障，而是并发协作的信号。重点不在消除锁，而在缩短锁持有时间、缩小锁范围、明确事务边界。定期做慢事务审计、关键路径 SQL 走查、压测时观察锁等待指标，比出问题再救火更有效。
