InnoDB行级锁实际触发取决于索引命中：WHERE条件走索引则锁单行，否则升级为表级锁或间隙锁组合；需通过INNODB_TRX等元数据表定位锁阻塞，死锁时MySQL回滚代价小的事务。
MySQL 的行级锁和表级锁到底怎么触发
InnoDB 默认用行级锁，但不是所有查询都会真的锁住单行。关键看是否命中索引——WHERE 条件没走索引时，会升级为表级锁（或间隙锁组合），导致意外阻塞。
常见误判场景：
-
SELECT ... FOR UPDATE或UPDATE语句中，WHERE id = ?走主键索引 → 精确锁单行 -
WHERE status = 'pending'且status没索引 → 扫描全表，每行加记录锁 + 间隙锁，实际接近表锁效果 -
INSERT INTO t VALUES (100)会加插入意向锁，与已有间隙锁冲突时直接等待
如何快速定位正在运行的锁和阻塞源头
别只看 SHOW PROCESSLIST，它不显示锁信息。真正有用的是 InnoDB 的三张元数据表：
SELECT * FROM information_schema.INNODB_TRX; SELECT * FROM information_schema.INNODB_LOCKS; SELECT * FROM information_schema.INNODB_LOCK_WAITS;
注意：INNODB_LOCKS 在 MySQL 8.0.1 之后已被移除，改用 performance_schema.data_locks；如果你用的是 5.7 或早期 8.0，上面三表仍有效。
实用技巧：
- 查长时间未提交事务：
SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60; - 结合
sys.innodb_lock_waits视图（需启用 sys schema）可直接看到谁在等谁、等了多久、SQL 是什么
死锁发生时 MySQL 怎么选 victim 回滚
MySQL 不随机挑，而是按「事务持有锁的代价」决定：回滚修改行数少、undo log 小的那个事务。所以小事务反而更容易被干掉。
典型死锁链路示例：
事务 A：UPDATE accounts SET balance = balance - 100 WHERE id = 1; 事务 B：UPDATE accounts SET balance = balance + 100 WHERE id = 2; 事务 A：UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- 等 B 的锁 事务 B：UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- 等 A 的锁
此时 MySQL 检测到环形等待，选一个回滚。日志里会记录类似：
Deadlock found when trying to get lock; try restarting transaction
应对要点：
- 应用层必须捕获这个错误码（
1213），并重试事务，不能静默失败 - 避免在事务里做 RPC、文件读写、用户输入等长耗时操作
- 按固定顺序访问多行（比如总是先更新
id小的记录），从源头减少环形可能
哪些配置能降低死锁概率但容易被忽略
默认配置对 OLTP 场景不够友好，几个关键项值得检查：
-
innodb_lock_wait_timeout：默认 50 秒，线上建议调成 10–30，避免一个慢事务拖垮整条线程池 -
innodb_deadlock_detect：默认 ON，高并发下检测开销大；若业务已规避环形访问，可关掉，靠超时机制兜底 -
transaction_isolation：避免用READ-COMMITTED以外的级别做高频更新——REPEATABLE-READ下间隙锁更激进，死锁面更宽
最常被漏掉的一点：没建好联合索引却依赖 ORDER BY + LIMIT 分页更新，导致扫描范围不可控，锁住大量无关行。
