什么时候该用行锁而不是表锁
InnoDB 默认在事务中执行
UPDATE、
DELETE、
SELECT ... FOR UPDATE或
SELECT ... LOCK IN SHARE MODE时加行锁，但前提是语句能走索引。如果
WHERE条件没命中任何索引（比如全表扫描），InnoDB 会退化为锁住所有索引记录 + 间隙（next-key lock），甚至可能升级为表级意向锁阻塞其他 DML。
实操建议：
检查执行计划：用EXPLAIN确认是否走了索引，尤其注意
type字段不能是
ALL或
index避免在非主键/非唯一索引字段上做范围查询后紧接更新，容易锁住大片间隙 写 SQL 时优先用主键或覆盖索引定位单行，例如
UPDATE t SET x=1 WHERE id = 123比
WHERE status = 'pending'更安全
共享锁（S）和排他锁（X）冲突的实际表现
共享锁（
SELECT ... LOCK IN SHARE MODE）允许多个事务并发读，但会阻塞其他事务获取排他锁；排他锁（
SELECT ... FOR UPDATE或写操作）则既阻塞其他 X 锁，也阻塞 S 锁。常见错误现象是：两个事务先后执行
SELECT ... FOR UPDATE查同一行，第二个会卡住直到第一个提交或回滚。
关键细节：
INSERT会对插入行加 X 锁，同时对插入位置的间隙加 gap lock（防止幻读）
UPDATE和
DELETE先加 S 锁判断是否满足条件，再升级为 X 锁——这意味着即使最终没更新到数据，也可能短暂持有锁 显式加 S 锁很少必要，除非你明确需要“读不阻塞写，但写必须等我读完”，否则直接用默认一致性读更轻量
如何避免死锁：从语句顺序到事务粒度
死锁不是锁多，而是多个事务以不同顺序访问相同资源。典型场景：事务 A 先锁行 1 再锁行 2，事务 B 反过来先锁行 2 再锁行 1，双方等待导致 InnoDB 回滚其中一个。
降低概率的关键动作：
所有业务逻辑按固定顺序访问表和行，比如总是先更新orders再更新
order_items，且行按主键升序处理 把多个相关更新合并进一个 SQL，比如用
INSERT ... ON DUPLICATE KEY UPDATE替代先查再更新 事务尽量短，不要在事务里做 RPC 调用、文件读写或用户输入等待 监控死锁日志：
SHOW ENGINE INNODB STATUS中的
LATEST DETECTED DEADLOCK段落，重点关注
WAITING FOR THIS LOCK TO BE GRANTED和
HOLDS THE LOCK(S)
READ COMMITTED 和 REPEATABLE READ 对锁行为的影响
隔离级别直接决定锁的持续时间和范围。在
REPEATABLE READ（InnoDB 默认）下，普通
SELECT是快照读，不加锁；但当前读（如
FOR UPDATE）会使用 next-key lock（记录锁 + 间隙锁），防止幻读。而
READ COMMITTED下，当前读只加 record lock，不锁间隙，所以不会阻止其他事务插入新行。
选哪个？
高并发写+频繁范围查询的场景（如后台批量改状态），用READ COMMITTED可减少间隙锁争用 需要强一致读（比如金融对账），且能接受更高锁开销，保留
REPEATABLE READ注意：修改隔离级别是会话级的，
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED即可，无需改全局配置
锁不是越细越好，也不是越少越好——它本质是数据一致性和并发性能之间的权衡。最容易被忽略的是：索引设计决定了你能锁多细，而事务边界决定了锁要扛多久。这两点没理清，调参数、换隔离级别都只是止痛片。
