查锁表应优先用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 且持续上升，往往是锁争用加剧的前兆，未必已死锁，但得马上查
死锁本身不可怕，可怕的是同一个业务路径反复触发——那说明设计上没处理好更新顺序或隔离级别，光靠调参解决不了。
