该用行锁而非表锁当且仅当SQL能走索引，否则会退化为间隙锁甚至表级锁；实操需用EXPLAIN确认索引使用、优先用主键定位、避免非索引字段范围查询后更新。
什么时候该用行锁而不是表锁
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即可，无需改全局配置
锁不是越细越好，也不是越少越好——它本质是数据一致性和并发性能之间的权衡。最容易被忽略的是：索引设计决定了你能锁多细，而事务边界决定了锁要扛多久。这两点没理清，调参数、换隔离级别都只是止痛片。
