order by + limit 不会自动缩小锁范围，反而常因索引缺失、顺序错配或扫描膨胀导致单行操作锁住大量行；根本原因是innodb加锁发生在执行扫描阶段，需逐行检查并加锁直至满足limit数量，而非语法层面截断。
加 ORDER BY 和 LIMIT 不会自动缩小锁范围，反而常因索引没走对、排序失效或扫描膨胀，把单行操作变成锁一片。
为什么 ORDER BY + LIMIT 容易锁住远超预期的行
MySQL 加锁行为取决于执行路径，不是语法看着“只取1条”就真只锁1行。常见诱因包括：
-
ORDER BY字段没索引，触发Using filesort→ 优化器可能全表扫描再排序，期间对所有扫描行加读锁（RR 级别下是 consistent read snapshot），FOR UPDATE场景下更会逐个加 record lock 或 gap lock - 联合索引顺序错，比如建了
INDEX (status, created_at)，但查WHERE created_at > '2026-01-01' ORDER BY status→ 不满足最左前缀，索引失效 - 非唯一索引 + 等值条件 +
ORDER BY，如WHERE status = 1 ORDER BY id，但status是普通二级索引 → InnoDB 会对所有status = 1的索引项及其间隙加 Next-key Lock，哪怕LIMIT 1 -
EXPLAIN中rows值远大于返回行数（比如rows=50000却只LIMIT 10）→ 扫描膨胀已发生，锁范围必然失控
怎么验证当前语句是否真的走对了索引
别靠猜测，用 EXPLAIN FORMAT=TRADITIONAL 盯死三处：
-
key列是否显示你期望的索引名？如果是NULL或PRIMARY（但你本意是走二级索引），说明没走对 -
Extra是否含Using filesort？有就是排序没走索引，风险极高 -
rows是否接近实际匹配行数？若差一个数量级，基本可判定扫描失控 - 进一步确认锁行为：执行
SELECT * FROM performance_schema.data_locks，看LOCK_DATA是否集中在某段密集值区间（比如一堆created_at = '2026-08-01'），这是间隙锁扩散的典型信号
真正能控锁的写法：游标分页 + 覆盖索引
放弃 OFFSET，改用主键或唯一字段做游标；同时确保查询字段全部落在索引中，避免回表：
- 原危险写法：
SELECT * FROM orders WHERE status = 1 ORDER BY created_at DESC LIMIT 10 OFFSET 100000 FOR UPDATE→ 扫描并锁住前 100010 行所有匹配记录+间隙 - 安全写法：
SELECT * FROM orders WHERE status = 1 AND created_at ，前提是 <code>INDEX (status, created_at)存在且顺序正确 - 更优写法（覆盖索引）：
SELECT order_no, status FROM orders WHERE user_id = 1001 ORDER BY id DESC LIMIT 1 FOR UPDATE，配合INDEX (user_id, id, order_no, status)→ 不回表，锁只落在二级索引页上单条记录 - 注意：游标值（如
created_at ）必须来自上一页最后一条的真实值，不能用 <code>MAX(created_at)全表查，否则该查询本身又成锁瓶颈
容易被忽略的细节：唯一性定义和隔离级别
业务上“应该唯一”的字段，MySQL 不认——它只看索引定义是否带 UNIQUE：
- 同样是
WHERE order_no = 'ORD123'，如果order_no没建UNIQUE INDEX，InnoDB 就按非唯一二级索引处理，加 Next-key Lock，可能锁住前后多个间隙 - RR 隔离级别下，
SELECT ... FOR UPDATE即使查不到记录，也会对查询范围加 gap lock；若并发请求都查同一个不存在的order_no，再叠加 INSERT，立刻死锁 - 若只是校验后更新，优先用
SELECT ... LOCK IN SHARE MODE代替FOR UPDATE，锁更轻，但需自行处理幻读（比如用INSERT ... ON DUPLICATE KEY UPDATE替代先查后插）
锁范围是否可控，不取决于你写了 LIMIT 1，而取决于 MySQL 实际扫描了多少行、加了多少锁。最可靠的控制手段，永远是让 WHERE 和 ORDER BY 同时命中联合索引的最左前缀，并确保该索引能覆盖查询所需字段。
