什么时候 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; <p>-- 事务 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 STATUS\G，末尾的
LATEST DETECTED DEADLOCK和
TRANSACTIONS部分直接给出锁冲突现场
注意：
performance_schema需提前开启相关 consumers 和 instruments，否则
data_locks为空。
