MySQL行锁在UPDATE时即加锁至事务结束，先更新后查询会延长锁持有时间导致阻塞；应将SELECT FOR UPDATE前置，控制事务规模，避免非一致性读，关键读写需加锁。
先更新再查询会卡住其他事务
MySQL 的行锁在 UPDATE 执行时就加上了，直到事务结束才释放。如果你在事务里先 UPDATE 一行，后又 SELECT ... FOR UPDATE 同一行或关联行，等于重复加锁、延长锁持有时间，别人想读写这行就得等你整个事务提交。
常见错误现象：Lock wait timeout exceeded 或大量 SHOW PROCESSLIST 显示 Updating / Locked 状态卡在同一个事务里。
- 把所有
SELECT（尤其是带FOR UPDATE或LOCK IN SHARE MODE）尽量提到事务最前面 - 如果后续
UPDATE依赖SELECT结果，那就必须先查；但如果只是“顺手查个日志”或“校验用”，考虑挪到事务外异步做 - 避免在事务里执行不确定耗时的逻辑（比如调外部 API、大表 COUNT），它会让锁白白挂着
INSERT 和 UPDATE 的顺序影响唯一键冲突概率
当事务里既有 INSERT 又有 UPDATE 涉及同一张表的唯一索引（比如 email 字段），顺序错了容易触发死锁或 Duplicate entry 回滚。
使用场景：用户注册（插入新记录）+ 同时更新统计表（如 user_count）；或幂等写入（先查再插，没查到才插）。
- 想确保插入不冲突？先
SELECT ... FOR UPDATE唯一键所在行（哪怕查不到），再INSERT—— 这能阻塞其他事务同时插入相同值 - 如果用
INSERT ... ON DUPLICATE KEY UPDATE，就别在它前面再SELECT同一条件，否则可能查到旧状态，导致误更新 -
REPLACE INTO本质是删+插，会触发两次索引查找和锁，比INSERT ... ON DUPLICATE KEY UPDATE更重，慎用
批量操作必须控制单次事务大小
一个事务里执行 1000 次 UPDATE，不是慢在 SQL 本身，而是锁住了 1000 行 + undo log 膨胀 + binlog 写入延迟，其他事务全被堵在第一个被锁的行上。
性能影响：事务越长，MVCC 版本链越长，SELECT 扫描开销越大；主从延迟也会明显升高。
- 单个事务不超过 50–100 行 DML，具体看单行数据大小和索引复杂度
- 用
INSERT INTO ... VALUES (...), (...), (...)批量插入，比循环单条INSERT快且锁更集中 - 不要在事务里用
UPDATE table SET col = col + 1 WHERE id IN (1,2,3,...1000)—— 改成按主键分片，每次 50 个 ID 提交一次
READ COMMITTED 下的非一致性读陷阱
很多人以为设了 SET TRANSACTION ISOLATION LEVEL READ COMMITTED 就不会幻读，其实它只保证当前语句看到已提交数据，但事务内多次 SELECT 仍可能拿到不同结果 —— 如果中间有别的事务插入了新行，而你的后续 UPDATE 又基于第一次 SELECT 的结果，逻辑就错了。
容易踩的坑：分页更新（查出第一页 ID 列表，再根据这些 ID 更新）、库存扣减（查剩余 10，然后 UPDATE ... SET stock = stock - 1），都可能因中间插入/修改失效。
- 关键业务逻辑中，所有读取必须配合加锁：比如
SELECT ... FOR UPDATE，哪怕只读不改 - 避免“先查后算再更新”的三段式，尽量用原子语句替代，例如
UPDATE order SET status = 'paid' WHERE id = ? AND status = 'unpaid' - 如果必须分步，把读和写放在同一个
SELECT ... FOR UPDATE里完成，比如用SELECT @stock:=stock FROM inventory WHERE item_id = ? FOR UPDATE，再立刻UPDATE
锁不是加得越少越好，而是加在真正需要保护的数据和时机上。顺序错一步，可能让锁从毫秒级拖成秒级，还看不出哪里写的不对。
