select for update 仅在显式事务且隔离级别非read uncommitted时生效；需走索引才能行锁，否则升表锁；锁满足where条件的索引记录，非数据行本身。
SELECT FOR UPDATE 在什么情况下才真正加锁
它只在事务中、且事务隔离级别不是 READ UNCOMMITTED 时生效；自动提交开启（autocommit=1）下，语句执行完立刻提交，锁也立刻释放——等于没锁。
- 必须显式开启事务：
BEGIN或START TRANSACTION，不能依赖隐式事务 - InnoDB 行锁生效的前提是查询能走索引；全表扫描会升级为表级锁（或大量行锁），极易引发死锁
-
SELECT FOR UPDATE锁的是“满足 WHERE 条件的索引记录”，不是数据行本身；如果 WHERE 条件无匹配行，通常不加任何锁（但某些版本会对间隙加锁） - 若用
SELECT FOR UPDATE NOWAIT，遇到锁会直接报错ERROR 1205 (40001): Deadlock found或ERROR 3572 (HY000): Statement aborted，而非阻塞等待
为什么 UPDATE 后再 SELECT FOR UPDATE 还会等锁
因为锁由事务持有，不是由语句持有。只要事务没提交，之前 SELECT FOR UPDATE 或 UPDATE 拿到的锁就一直存在——后续任何会冲突的加锁操作都会被阻塞。
- 常见误判：以为只有
SELECT FOR UPDATE才加锁，其实UPDATE、DELETE、INSERT ... ON DUPLICATE KEY UPDATE同样会持锁 - 锁类型取决于查询条件和索引：主键/唯一索引 → 记录锁；非唯一索引 → 间隙锁（Gap Lock）或临键锁（Next-Key Lock）
- 执行
SHOW ENGINE INNODB STATUS\G能看到当前阻塞链和持锁事务，重点关注TRANSACTIONS和LOCK WAIT部分
如何避免 SELECT FOR UPDATE 导致的死锁
死锁不是锁太多，而是多个事务以不同顺序争抢同一组资源。InnoDB 虽能检测并回滚一个事务，但业务逻辑可能已错乱。
- 所有涉及加锁的业务路径，统一按相同字段顺序访问记录（比如始终按
id ASC查询） - 尽量缩短事务时间：查到数据后尽快完成更新、提交，不要在事务里做 HTTP 请求、文件读写等耗时操作
- 避免在循环中反复
SELECT FOR UPDATE；应一次性查出所有待处理主键，再用WHERE id IN (...)批量加锁 - 监控
Innodb_row_lock_waits和Innodb_row_lock_time_avg状态变量，及时发现锁争用上升趋势
MySQL 8.0+ 中 LOCK IN SHARE MODE 和 FOR UPDATE 的关键区别
二者都加行级锁，但意图和兼容性完全不同：SELECT FOR UPDATE 加排他锁（X），阻止其他事务读写；LOCK IN SHARE MODE 加共享锁（S），允许其他事务加 S 锁，但拒绝 X 锁。
- 典型误用：用
LOCK IN SHARE MODE做库存扣减，结果两个事务同时读到剩余 1，都判断“够减”，最终超卖 -
SELECT FOR UPDATE在可重复读（RR）下默认使用 Next-Key Lock，既锁记录又锁间隙，防止幻读；LOCK IN SHARE MODE同样如此，但兼容性更强 - 如果只是想防止别人改，自己不改，且能接受并发读，
LOCK IN SHARE MODE更轻量；但凡要写，必须用FOR UPDATE - 注意：
SELECT ... FOR UPDATE在 RR 隔离级别下，即使查询条件命中唯一索引，InnoDB 仍可能对下一个键加间隙锁——这点容易被忽略
Innodb_row_lock_time_max 突然飙升时，能不能快速定位到那个忘了提交的事务。 
