mysql在InnoDB中自动使用行锁当且仅当WHERE条件走索引、为等值查询且能精确命中记录；否则退化为多个行锁+意向排他锁或间隙锁，效果近似表锁。
什么时候 MySQL 会自动用行锁而不是表锁
InnoDB 引擎在满足「使用索引条件且能精确命中记录」时，才可能加行锁；否则退化为表锁或间隙锁。关键看 WHERE 条件是否走了索引、是否是等值查询、索引是否覆盖扫描范围。
-
select ... for UPDATE或UPDATE/delete语句中，若WHERE id = 100（id是主键），则只锁该行 - 若写成
WHERE name = 'alice'，而name没有索引，InnoDB 会扫全表——此时实际加的是**多个行锁 + 一个意向排他锁（IX）**，但效果接近表级阻塞 - 若
name有索引但查询是WHERE name LIKE 'ali%'，可能锁住索引范围内的所有行，甚至包含间隙（next-key lock）
显式加表锁的典型场景与风险
MyISAM 默认表锁，InnoDB 中需用 LOCK TABLES ... WRITE 手动加表级锁，常见于数据归档、批量重建统计表等低频维护操作。
- 执行
LOCK TABLES orders WRITE后，其他事务对orders的任何读写都会被阻塞，直到你UNLOCK TABLES - 该锁不遵守事务边界：即使在事务内加了表锁，
ROLLBACK也不会释放它 - 一旦连接异常断开，MySQL 会自动释放其持有的表锁；但若忘记
UNLOCK TABLES，可能长时间阻塞线上业务
行锁导致死锁的常见模式
死锁不是锁多，而是加锁顺序不一致。InnoDB 能检测并回滚其中一个事务，但应用层必须捕获 Deadlock found when trying to get lock 错误并重试。
-- 事务 A UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- 事务 B（同时执行） UPDATE accounts SET balance = balance - 200 WHERE id = 2; UPDATE accounts SET balance = balance + 200 WHERE id = 1;
两个事务分别持有对方下一步需要的行锁，形成环路。避免方式：
- 所有业务逻辑按固定字段顺序更新（如始终按
id升序更新多行） - 尽量缩短事务长度，避免在事务中做 rpc、文件读写等耗时操作
- 用
SELECT ... FOR UPDATE ORDER BY id显式控制加锁顺序
如何确认当前锁状态与等待关系
别只看 SHOW PROCESSLIST，它不显示锁信息。真正有用的是：
-
SELECT * FROM information_schema.INNODB_TRX：查当前活跃事务、运行时间、SQL、事务状态 -
SELECT * FROM information_schema.INNODB_LOCK_WAITS：查谁在等谁的锁（需关联INNODB_TRX看具体 SQL） -
SELECT * FROM information_schema.INNODB_LOCKS（MySQL 5.7+ 已废弃，8.0 不再提供）→ 改用performance_schema.data_locks - 最实用的一条命令：
SHOW ENGINE INNODB STATUSG，末尾的LATEST DETECTED DEADLOCK和TRANSACTIONS部分直接给出锁冲突现场
注意：performance_schema 需提前开启相关 consumers 和 instruments，否则 data_locks 为空。