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 分页更新，导致扫描范围不可控，锁住大量无关行。