加 LIMIT 1 是为避免全表扫描导致过度锁定，降低死锁概率和提升并发性能；前提是 WHERE 条件字段必须有有效索引，否则仍会锁大量无关行。
为什么 SELECT ... FOR UPDATE 要加 LIMIT 1
因为不加 LIMIT 1 时，MySQL 可能会锁住多行甚至全表，而你实际只需要锁住目标那一行 —— 这不是“更安全”，是过度锁定，反而抬高死锁概率、拖慢并发。
常见错误现象：SELECT status FROM t_goods WHERE id = 1 FOR UPDATE 看似只查一行，但如果 id 字段没有索引，InnoDB 会退化为全表扫描 + 行锁，所有被扫描过的行都会被加上 X 锁（即使最终结果只有 1 行）。线上曾有案例因此锁住上万行，导致后续订单事务集体等待超时。
- 必须确保
WHERE条件中的字段已建索引（如id是主键或唯一索引）；否则LIMIT 1也救不了扫描范围 -
LIMIT 1不影响语义正确性：你要更新的本就是单条记录，加了它只是提前终止扫描，让 InnoDB 尽快释放未命中行的锁 - 在唯一索引前提下，
SELECT ... FOR UPDATE LIMIT 1和不加LIMIT 1的锁行为一致；但一旦索引失效（比如隐式类型转换：WHERE id = '1'而id是INT），不加LIMIT 1就会暴露风险 - 某些 ORM 自动生成的 SQL（如 Laravel Eloquent 的
where(...)->forUpdate()）默认不带LIMIT，需手动干预或配置
FOR UPDATE 在非唯一条件下的真实锁行为
如果你写的是 SELECT * FROM t_orders WHERE user_id = 123 FOR UPDATE，且 user_id 没有索引，InnoDB 会锁住整张表所有行 —— 即使最终只返回 5 条。这不是 bug，是 InnoDB 行锁实现机制决定的：它只能对“实际访问到的行”加锁，而全表扫描就等于访问了所有行。
使用场景：秒杀库存扣减中，按商品 ID 扣减是安全的（主键索引），但按状态批量查询待处理订单（WHERE status = 1）时，若 status 无索引，FOR UPDATE 就成了隐形表锁炸弹。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 加索引是最根本解法；
LIMIT 1是兜底手段，不能替代索引 - 如果业务确实需要按非索引字段锁定，考虑先用普通
SELECT查出主键列表，再用IN (..., ..., ...)+FOR UPDATE显式锁定 —— 但要注意IN列表长度和执行计划是否走索引 - InnoDB 的间隙锁（Gap Lock）会在范围查询中自动启用，
WHERE user_id > 100 FOR UPDATE即使没匹配到数据，也可能锁住索引间隙，这点常被忽略
事务提交前，锁到底持有多久
锁持续到事务结束（COMMIT 或 ROLLBACK），不是语句执行完就释放。很多人误以为 SELECT ... FOR UPDATE 执行完、紧接着 UPDATE 完就没事了，其实只要事务没提交，锁就一直占着。
容易踩的坑：
- 在应用层开启事务后，执行
SELECT ... FOR UPDATE，然后调用外部 HTTP 接口生成订单 —— 这个网络耗时可能长达几百毫秒甚至秒级，期间锁一直挂着，其他下单请求全部排队 - 忘记写
COMMIT，连接被复用或异常中断，锁可能滞留几分钟，直到连接超时被 MySQL 主动 kill - Spring @Transactional 默认传播行为是
REQUIRED，嵌套调用时事务边界易混淆，导致锁持有时间远超预期
复杂点在于：锁的粒度、持有时间、索引有效性三者交织。哪怕语法完全正确，只要其中一环松动（比如 DBA 改了索引、应用加了新字段导致隐式转换），FOR UPDATE 就可能从“精准狙击”变成“地毯轰炸”。
