SELECT FOR UPDATE本身不导致长事务，但会暴露或加剧长事务问题；真正拖住数据库的是事务未及时提交、锁后嵌套耗时操作、索引失效扩大锁范围，以及未设置锁等待超时。
SELECT FOR UPDATE 本身不导致长事务，但会暴露或加剧长事务问题
很多人误以为 SELECT FOR UPDATE 是“慢操作”，其实它执行极快——真正拖住数据库的是后续业务逻辑没及时走完、或者事务边界没控制好。SELECT FOR UPDATE 只是把锁挂上了，而锁的生命周期完全绑定在事务上：事务不提交，锁就不释放。所以问题不在“选+锁”这一步，而在“锁之后干了什么、多久才 COMMIT”。
常见长事务诱因：锁后嵌套耗时操作
典型错误是把网络调用、RPC、文件读写、复杂计算甚至人工审核塞进同一个事务里。例如：
- 查库存：
SELECT stock FROM products WHERE id = 123 FOR UPDATE - 调第三方风控接口（耗时 800ms）
- 生成 PDF 发货单（同步生成，耗时 1.2s）
- 发邮件通知（SMTP 延迟不可控）
- 最后才
UPDATE和COMMIT
整个事务持续超 2 秒，期间所有想扣减 id = 123 库存的请求全被阻塞排队。这不是 SELECT FOR UPDATE 的锅，而是事务粒度失控。
索引失效让锁范围扩大，间接拉长等待链
当 WHERE 条件没走索引，SELECT FOR UPDATE 会升级为表锁或大面积间隙锁。比如：
SELECT * FROM orders WHERE status = 'pending' AND created_at > DATE_SUB(NOW(), INTERVAL 1 HOUR) FOR UPDATE;
若 status 或 created_at 没联合索引，MySQL 可能扫描几千行并逐个加锁。这时不仅本事务变重，其他想更新任意一行 pending 订单的事务也得等——锁等待雪球越滚越大，监控里就表现为“大量 SELECT FOR UPDATE 长时间未完成”。
应用层未设锁等待超时，死等导致假性长事务
默认情况下，MySQL 会无限期等待锁（除非被 kill）。一个被阻塞的 SELECT FOR UPDATE 看似“卡住”，实则是另一个更早的事务迟迟不提交。解决方式不是忍着，而是主动设限：
-
SELECT ... FOR UPDATE WAIT 3（MySQL 8.0+）：最多等 3 秒，超时抛Lock wait timeout exceeded -
SELECT ... FOR UPDATE NOWAIT：立即失败，适合幂等重试场景 - 应用代码里配 JDBC 的
lockWaitTimeout或 ORM 的超时参数
不设超时，等于把线程/连接资源交给未知风险；设了超时，至少能把问题显性化、可监控、可重试。
最易被忽略的一点：锁持有时间 ≠ SQL 执行时间。哪怕 SELECT FOR UPDATE 本身只花 0.5ms，只要它后面跟着一个 5 秒的 HTTP 调用，整个事务就变成 5 秒级锁持有者——而别人眼里的“慢查询”日志里，只会记下那条毫秒级的 SELECT。
