SELECT ... FOR UPDATE 拖垮并发因其本质是“查+加行锁+等锁释放”，高并发下易形成锁等待链；需确保 WHERE 条件走有效索引，避免全表扫描或事务中混入慢逻辑。
为什么 SELECT ... FOR UPDATE 会拖垮并发？
它不是“查数据”，而是“查+加行锁+等锁释放”，在高并发下极易形成锁等待链。尤其当查询没走索引、扫描范围大，或事务里混着慢逻辑（比如 HTTP 调用、文件读写），SELECT ... FOR UPDATE 持锁时间直接拉长数秒——其他事务全卡在那条语句上。
- 务必确认 WHERE 条件字段有有效索引，否则升级为表锁或间隙锁，影响面远超预期
- 避免在事务开头就执行
SELECT ... FOR UPDATE，更别把它和业务无关操作（如日志打点、缓存更新）包进同一事务 - 如果只是校验后插入（如防重复下单），优先用唯一索引 +
INSERT ... ON DUPLICATE KEY UPDATE，绕过显式锁
如何让 UPDATE 不锁整行甚至不锁？
MySQL 的行锁实际是“索引记录锁”，锁对象是索引项，不是数据行本身。所以锁的粒度和行为完全取决于你 UPDATE 时是否命中索引、是否修改索引列、是否触发二级索引更新。
- UPDATE 必须走主键或唯一索引，否则可能锁住多个索引区间（如 range scan 触发间隙锁）
- 避免
UPDATE t SET status = 'paid' WHERE user_id = ? AND status = 'pending'这类带非索引条件的语句——status若无索引，MySQL 可能先扫全表再过滤，锁住所有扫描过的记录 - 如果只更新非索引字段，且 WHERE 精确命中主键，锁仅作用于聚簇索引记录，不涉及二级索引维护，开销最小
innodb_lock_wait_timeout 设太小反而更卡？
设成 1 秒看似“快速失败”，但真实场景中，它会让大量请求在锁等待 1 秒后抛出 Lock wait timeout exceeded，然后重试——而重试大概率又撞上同一把锁，形成“重试风暴”，QPS 没涨，错误率飙升。
- 默认 50 秒其实更合理：给真正长事务留出完成机会，也避免盲目重试
- 真正该做的是监控
Innodb_row_lock_waits和Innodb_row_lock_time_avg，定位哪条 SQL/哪个业务路径持续持锁 - 若必须降超时，配合应用层做退避重试（如指数退避），而不是简单 catch 后立即重放
事务里混着 SLEEP() 或远程调用？赶紧拆掉
MySQL 不知道你在事务里调了 RPC 或等消息队列响应，它只认“BEGIN 到 COMMIT/ROLLBACK 之间的时间”——这期间所有锁一直挂着，不管你在干啥。
- 把耗时操作（如调第三方支付接口、发 MQ、生成 PDF）全部移到事务外，只在事务内做原子性 DB 操作
- 如果必须“先锁再调外部服务”，至少用
SELECT ... FOR UPDATE NOWAIT尝试获取锁，失败立刻返回，不等 - 考虑用最终一致性：先落库（状态设为 processing），异步任务轮询处理，成功后再 UPDATE 状态——锁持有时间压到毫秒级
