SQL索引范围收缩是查询优化器基于B+ Tree有序性、最左前缀原则对扫描边界确定性裁剪的过程；等值条件连续匹配可逐级收缩，范围条件后字段失效，函数操作、隐式转换、OR及统计过期会导致收缩退化。

SQL数据库索引的条件推导与范围收缩，本质是查询优化器利用索引结构（B+ Tree）逐步缩小数据扫描边界的过程。它不是“猜”或“过滤”，而是基于有序性、最左前缀和值分布的确定性裁剪。

索引如何实现范围收缩

以B+ Tree索引为例，所有键值按升序物理排列，叶子节点形成双向链表。当执行 WHERE age > 20 AND age 时：

• 优化器定位到 age=20 的右侧第一个叶节点（下界），再定位到 age=30 的左侧第一个叶节点（上界）
• 直接跳过树中所有小于20和大于等于30的分支路径
• 仅遍历这两个边界之间的连续叶节点块——这就是“范围收缩”的实质：从全表扫描 → 全索引扫描 → 索引范围扫描

条件顺序影响收缩效果

复合索引 (city, age, name) 的字段顺序决定了收缩能力：

• WHERE city = 'Beijing'：可收缩到该 city 的全部数据块
• WHERE city = 'Beijing' AND age BETWEEN 25 AND 35：进一步收缩到该 city 内指定 age 区间
• WHERE age > 25：无法使用该索引——不满足最左前缀，无法定位起始位置
• WHERE city = 'Beijing' AND name = 'Li'：name 不在 age 之后连续匹配，只能用到 city，age 被跳过，name 无法生效

等值 + 范围组合的截断规则

一旦出现范围条件（>, , BETWEEN, LIKE 'abc%'），其右侧所有字段的索引能力即被截断：

• INDEX(a, b, c, d)
• WHERE a = 1 AND b = 2 AND c > 10 → 可用 a、b、c；d 不可用
• WHERE a = 1 AND b > 5 AND c = 10 → 可用 a、b；c 因 b 是范围而失效
• 注意：IN 和 = 视为等值，不截断；LIKE 'prefix%' 算范围但可走索引；LIKE '%suffix' 不走索引

收缩失效的常见诱因

即使有索引，范围收缩也可能退化为全索引扫描甚至全表扫描：

• 对索引字段做函数操作：WHERE YEAR(create_time) = 2025 → 破坏有序性，无法定位边界
• 隐式类型转换：WHERE mobile = 13800138000（mobile 是 VARCHAR）→ 引擎转成数字比较，索引失效
• OR 连接非全索引字段：WHERE a = 1 OR b = 2，若只有 a 上有索引，b 部分无法收缩，整体可能放弃索引
• 统计信息过期：优化器误判选择性，认为全表扫描比索引范围扫描更快