SQL 数据库锁监控与死锁排查

查锁表应优先用information_schema.innodb_trx和innodb_lock_waits，而非show processlist；死锁日志中weight小者被回滚，lock_mode x locks rec but not gap为行锁；select … for update未走索引会锁全表；监控需关注错误日志死锁记录及innodb_row_lock_time_avg趋势。

怎么查当前数据库里谁在锁表

直接看 information_schema.INNODB_TRX 和 information_schema.INNODB_LOCK_WAITS，这是最轻量、不依赖额外权限的方式。mysql 5.7+ 默认开启这些视图，不需要开 performance_schema 就能拿到活跃事务和阻塞关系。

常见错误是只查 SHOW PROCESSLIST，它只能看到连接状态，看不到事务锁等待链。比如一个事务卡在 UPDATE 上不动，PROCESSLIST 显示 Updating，但你不知道它被谁锁了。

• 先执行 SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT'; 找出正在等锁的事务
• 再用 SELECT * FROM information_schema.INNODB_LOCK_WAITS; 关联 REQUESTING_TRX_ID 和 BLOCKING_TRX_ID，定位谁在持锁
• 最后查 INNODB_LOCKS（MySQL 5.7）或 performance_schema.data_locks（8.0+）看具体锁在哪行、哪个索引上

死锁日志里怎么看关键信息

MySQL 每次死锁都会写一条完整记录到错误日志（Error_log），不是所有 dba 都会翻——但它比任何监控工具都准，因为它是唯一真实触发点。

容易忽略的是：日志里两个事务的 TRANSACTION 段末尾有 mysql tables in use 和 locked tables，这告诉你是否用了表锁（比如 LOCK TABLES）；而 WEIGHT 值小的那个事务会被选为牺牲者，不是“先来的就赢”。

• 找 *** (1) TRANSACTION: 和 *** (2) TRANSACTION: 两段，分别对应两个参与者
• 重点看每段里的 lock_mode X locks rec but not gap —— 表示行锁（X 是排他锁），lock_mode S 是共享锁，gap before rec 是间隙锁
• 最后一行 *** WE ROLL BACK TRANSACTION (2) 明确告诉你谁被回滚了

为什么 SELECT ... FOR UPDATE 有时锁整张表

不是语句本身的问题，而是它没走索引时退化成表级扫描锁。InnoDB 的行锁必须依赖索引，没有可用索引，就只能对聚簇索引（主键）全扫，等于锁住所有行。

典型场景：给 name 字段加了索引，但查询条件写成 WHERE name LIKE '%abc'，导致索引失效；或者字段类型不一致，比如 WHERE user_id = '123'（user_id 是 int），触发隐式转换，索引也失效。

• 执行前一定用 EXPLAIN 看 type 是否为 range/ref，不是 ALL 或 index
• 检查 possible_keys 和 key 是否非空，且一致
• 注意字符集差异：比如 utf8mb4_bin 和 utf8mb4_0900_as_cs 比较时可能不走索引

监控死锁频率该看哪些指标

别只盯着 innodb_deadlocks 这个全局计数器——它清零重启就丢，也没时间维度。真正有用的是从慢日志或性能事件里捞出带死锁标记的 SQL，再聚合分析。

MySQL 8.0 可以开 performance_schema.events_statements_history_long，配合过滤 SQL_TEXT LIKE '%FOR UPDATE%' AND EVENT_NAME = 'statement/sql/select'，再关联锁等待事件。但更实际的做法是定期解析错误日志，提取死锁发生时间 + 涉及表 + 事务堆栈。

• 用 grep -A 20 'Deadlock found' /var/log/mysql/error.log 快速抓最近几条
• 关注重复出现的表名和 SQL 模式，比如总在 UPDATE order SET status=2 WHERE user_id=? AND status=1 上死锁，说明并发更新同一用户订单时缺乏串行化控制
• innodb_row_lock_time_avg 超过 50ms 且持续上升，往往是锁争用加剧的前兆，未必已死锁，但得马上查

死锁本身不可怕，可怕的是同一个业务路径反复触发——那说明设计上没处理好更新顺序或隔离级别，光靠调参解决不了。