倒序索引本身不扩大锁范围，真正导致锁膨胀的是范围查询中误用降序索引或索引列顺序与where+order by不匹配，迫使优化器退化为全索引/全表扫描。
倒序索引本身不会直接导致锁范围扩大；真正引发锁膨胀的是「在范围查询中误用降序索引」，或「索引列顺序与 WHERE + ORDER BY 不匹配」，从而迫使优化器退化为全索引扫描甚至全表扫描。
为什么 ORDER BY a DESC 会锁更多行？
这不是降序索引的“错”，而是 B+ 树物理结构决定的：单列降序索引（如 INDEX (a DESC)）在做 WHERE a > 100 这类范围扫描时，InnoDB 无法像升序索引那样高效定位起始点并按顺序遍历——它得先找到最大值附近，再反向跳查，最终常退化为扫描整个索引页。此时若配合 LIMIT 或高并发更新，极易触发大量间隙锁（Gap Lock）或临键锁（Next-Key Lock）。
- 现象：慢日志里
rows_examined远高于实际返回行数，innodb_row_lock_time_avg飙升 - 验证方式：执行
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX\G，观察trx_rows_locked和trx_isolation_level - 关键误区：以为建了
INDEX (a DESC)就能同时支持WHERE a > 100 ORDER BY a DESC—— 实际上该场景下，INDEX (a ASC)效果更好，且锁更少
哪些组合能真正减少锁？
只有当「等值条件 + 严格匹配的 DESC 排序」共存时，降序索引才既跳过 Using filesort，又控制扫描范围。核心是让 WHERE 构成最左前缀，且 ORDER BY 完全对齐索引定义方向。
- ✅ 有效：索引为
INDEX (status, created_at DESC)，查询为WHERE status = 'PAID' ORDER BY created_at DESC - ❌ 无效：同上索引，但查询是
WHERE status IN ('PAID','REFUND') ORDER BY created_at DESC（IN算范围，status 列后失效） - ❌ 无效：索引为
INDEX (user_id DESC, amount DESC)，但查询只写ORDER BY user_id DESC（跳过 amount，方向链断裂） - ⚠️ 高风险：索引含
DESC但 WHERE 条件含隐式转换，例如WHERE user_id = '123'（user_id 是BIGINT），会导致索引完全失效，锁全表
如何验证锁是否真的被收敛？
不能只看 EXPLAIN 的 key 字段是否命中，必须结合运行时锁视图和执行计划中的扫描行数判断。
- 第一步：加
SELECT ... FOR UPDATE模拟业务逻辑，再查INFORMATION_SCHEMA.INNODB_LOCK_WAITS和INNODB_LOCKS - 第二步：对比
EXPLAIN FORMAT=TREE输出，确认是否有filesort节点，以及rows是否接近你期望过滤后的结果集大小 - 第三步：开启
innodb_status_output_locks = ON，在SHOW ENGINE INNODB STATUS的TRANSACTIONS部分观察锁记录详情 - 特别注意：MySQL 8.0.20+ 才支持
FORMAT=TREE，旧版本只能靠Handler_read_next和Handler_read_rnd_next差值估算扫描行为
真正容易被忽略的点是：降序索引不是性能开关，而是「精确匹配工具」。一旦 WHERE 条件松动、列顺序错位、或类型不一致，它就立刻失效，且比普通索引更难排查——因为 EXPLAIN 可能仍显示 key 命中，但实际执行已退化。别迷信 DESC 关键字，盯住 rows 和锁视图才是真相。
