MySQL行锁遵循两阶段锁协议，SELECT ... FOR UPDATE等会延长锁持有至事务结束；仅两类SELECT需留在事务内：作为写操作判断依据或读取后立即更新同一行；其余应移出事务。
为什么SELECT会延长行锁持有时间
MySQL 的行锁不是“用完即放”，而是遵循两阶段锁协议：锁在需要时加上，但要等到事务 COMMIT 或 ROLLBACK 才统一释放。这意味着，哪怕你只是在事务里顺手查了一条日志、校验了一个状态，只要用了 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE，这把锁就会一直挂着，直到整个事务结束。
常见错误现象：Lock wait timeout exceeded、SHOW PROCESSLIST 中大量线程卡在 Updating 或 Locked 状态、慢查询日志里出现明显延迟的 SELECT 语句。
哪些SELECT必须留在事务内
只有两类 SELECT 真正需要和后续写操作绑定在同一个事务里：
- 用于决定是否执行写操作的判断依据（例如：查库存是否充足，再决定扣减）
- 读取后立即要加锁更新的同一行（例如：
SELECT balance FROM account WHERE id = 123 FOR UPDATE，紧接着UPDATE account SET balance = balance - 100）
其余所有情况——比如记录审计日志、生成报表快照、同步到外部系统前的预览——都应移出事务。它们不参与一致性约束，却白白拖长锁生命周期。
如何安全地把耗时SELECT移出事务
关键不是“删掉”，而是“换地方”。实操建议如下：
- 把非关键
SELECT拆到事务外，用自动提交模式执行；若需保证最终一致性，可在事务提交后异步补发消息或触发回调 - 如果必须依赖事务内读到的数据（如用户 ID），可先在事务中只查主键或轻量字段，把大字段、关联表、聚合计算等重逻辑挪到事务外再查
- 避免在事务中调
COUNT(*)、GROUP BY大表、JOIN多张宽表——这些极易因未走索引或扫描行数多而放大锁范围 - 对“只读但需强一致”的场景，改用
SELECT ... LOCK IN SHARE MODE并确保它也前置，不要夹在两个UPDATE中间
容易被忽略的隐式锁持有点
有些操作你以为没加锁，其实悄悄占着资源：
-
INSERT ... ON DUPLICATE KEY UPDATE对冲突行会隐式加X锁，如果插入前先做了复杂子查询，那个子查询本身虽不加锁，但会让整个语句执行更久，间接拉长锁持有窗口 -
REPLACE INTO实际是DELETE + INSERT，会先对匹配行加锁再删，比普通INSERT更重 - 触发器里执行的隐式
SELECT或UPDATE，也会被纳入当前事务锁生命周期
真正难优化的从来不是那几行 UPDATE，而是事务边界划得模糊、读写职责混在一起的“惯性写法”。锁不会自己说话，但它卡住时，日志和 SHOW ENGINE INNODB STATUS\G 里的 TRANSACTION 块会说得很清楚。
