SELECT FOR UPDATE在点查询下仍危险，因其本质是“查+加行锁+等待释放”，若事务未及时提交或混入非DB操作，会导致锁悬停数秒、引发锁等待链；必须用EXPLAIN确认走主键索引（type:const），否则可能退化为间隙锁或表锁。
高并发点查询（如按主键或唯一键查单行）本身不构成锁瓶颈，真正拖垮吞吐量的是“查+锁+等”的组合逻辑——尤其是 SELECT FOR UPDATE 和非原子的“查再改”链路。
为什么 SELECT FOR UPDATE 在点查询场景下反而最危险
它不是单纯的“查”，而是“查 + 加行锁 + 等待锁释放”。哪怕你 WHERE 条件是 id = 123，只要事务没及时提交、或中间混了日志打点、HTTP 调用，锁就会悬停数秒。其他所有想更新同一行的请求全卡在那条语句上，形成锁等待链。
- 必须用
EXPLAIN确认该语句确实走了主键索引（type: const，key显示主键名），否则可能退化为间隙锁甚至表锁 - 禁止把
SELECT FOR UPDATE放在事务开头；应尽量靠近UPDATE或COMMIT前执行，缩短持锁时间 - 如果只是校验后插入（如防重复下单），直接用
INSERT INTO ... ON DUPLICATE KEY UPDATE，它只做一次索引查找+一次行锁，无竞态、无等待
哪些“点查询”写法会意外放大锁范围
表面是点查，实际锁了一片。根本原因在于 MySQL 的行锁对象是“索引记录”，不是数据行——锁的粒度完全取决于你是否命中索引、是否触发二级索引维护、是否引发间隙锁。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
UPDATE t SET status = 'done' WHERE order_no = 'ORD123'：若order_no没建唯一索引，MySQL 可能全表扫描再过滤，锁住所有扫描过的记录 -
UPDATE t SET cnt = cnt + 1 WHERE user_id = 100 AND status = 'active'：若status无索引，WHERE 中的status = 'active'会导致扫描大量user_id = 100的行并加锁 - 在 RC 隔离级别下仍要慎用范围条件（如
WHERE created_at > '2026-06-01'），即使只查一行，也可能因索引结构触发间隙锁
替代方案比调参更有效：绕过显式锁
很多所谓“点查询加锁”需求，本质是业务逻辑需要原子性保障，而非真要数据库锁。优先用数据库原生原子能力替代手写锁逻辑。
- 计数类操作（如库存扣减）：用
UPDATE t SET stock = stock - 1 WHERE id = 123 AND stock >= 1，检查影响行数是否为 1，失败即库存不足——无需SELECT FOR UPDATE - 状态机推进（如订单从 pending → paid）：用
UPDATE orders SET status = 'paid' WHERE id = 123 AND status = 'pending'，同样靠影响行数判断是否成功 - 防重插入：确保
UNIQUE KEY (biz_id)存在，然后统一走INSERT INTO t (biz_id, ...) VALUES (...) ON DUPLICATE KEY UPDATE updated_at = NOW()
真正卡吞吐的从来不是“查得慢”，而是“锁得久、锁得宽、锁得不必要”。优化重点不在怎么让锁更快，而在怎么让锁更少、更短、更精准——多数时候，答案是根本不加锁。
