SELECT ... FOR UPDATE 只锁满足 WHERE 条件且能走索引的行；无索引、索引失效或范围过大时会退化为锁索引范围甚至表级锁，需确保 WHERE 字段有有效索引并避免函数/类型转换。
MySQL 中 SELECT ... FOR UPDATE 到底锁哪几行？
它只锁满足 WHERE 条件且能走索引的行——没索引、索引失效、或条件范围过大时，会退化为锁整个索引范围，甚至升级成表级锁。
常见错误现象：SELECT * FROM orders WHERE status = 'pending' FOR UPDATE 在 status 字段无索引时，可能锁住全表，导致其他事务写入阻塞。
- 必须确认
WHERE字段有有效索引（可用EXPLAIN验证key和rows） - 避免在索引字段上用函数或隐式类型转换，例如
WHERE DATE(created_at) = '2024-01-01'会让索引失效 - 复合索引要注意最左前缀匹配，
INDEX(a, b)支持WHERE a = ?或WHERE a = ? AND b = ?，但不支持仅WHERE b = ?
什么时候 UPDATE 会意外触发表级锁？
InnoDB 一般只锁行，但某些操作会让引擎放弃行锁机制，直接升级为意向锁+表级排他行为，本质是优化器判断“锁太多行不如锁表快”。
典型场景：批量更新无主键/无索引表、UPDATE 涉及未提交的长事务扫描、或执行计划返回大量 rows（如 > 20% 表数据）。
- 检查执行计划：
EXPLAIN UPDATE ...看rows是否异常高 - 对大表批量更新，务必加
LIMIT分批，并用主键范围控制（如WHERE id BETWEEN ? AND ?） - 避免在事务中先
SELECT ... FOR UPDATE扫描万级行，再逐条UPDATE—— 这些行锁会累积并加剧锁等待
LOCK TABLES WRITE 和行级锁能不能混用？
不能。一旦执行 LOCK TABLES orders WRITE，当前连接进入“显式表锁模式”，后续所有语句（包括 SELECT）都受该锁约束，InnoDB 行锁机制完全失效，且其他连接无法对该表做任何读写。
这不是并发控制手段，而是运维级阻断操作，常被误用于“防止并发修改”，结果反而制造雪崩。
-
LOCK TABLES只应在低峰期维护时用，且必须配对UNLOCK TABLES - 应用层需要并发控制，请用行锁 + 重试逻辑，而不是绕过 InnoDB 机制
- 若业务真存在高频冲突更新同一行，考虑拆分状态字段、引入版本号（
version）或改用乐观锁
不同隔离级别下，行锁行为差异在哪？
核心区别不在“是否加锁”，而在“锁什么”和“持续多久”。可重复读（RR）下，SELECT ... FOR UPDATE 会加临键锁（next-key lock），既锁记录又锁间隙；读已提交（RC）下只锁记录本身，不锁间隙。
这意味着 RC 下可能发生幻读（新插入满足条件的行），而 RR 能阻止，但代价是更大范围的锁等待。
- 高并发插入场景（如订单流水），RC 更友好；强一致性要求（如库存扣减防超卖），RR 更稳妥
- RC 下
UPDATE不会阻塞其他事务向同一间隙插入，但 RR 会——这点常被忽略，导致压测时出现意料外的锁等待链 - MySQL 8.0+ 默认 RR，切到 RC 前需确认所有业务 SQL 已适配幻读风险
锁的粒度从来不是越小越好，而是要看实际访问路径是否稳定、索引是否靠谱、事务是否够短。很多性能问题，其实出在 EXPLAIN 没看，或者 SHOW ENGINE INNODB STATUS 里的 TRANSACTIONS 和 LOCK WAIT 段落被跳过了。
