SQL索引范围收缩是查询优化器基于B+ Tree有序性、最左前缀原则对扫描边界确定性裁剪的过程；等值条件连续匹配可逐级收缩，范围条件后字段失效，函数操作、隐式转换、OR及统计过期会导致收缩退化。
SQL数据库索引的条件推导与范围收缩，本质是查询优化器利用索引结构（B+ Tree）逐步缩小数据扫描边界的过程。它不是“猜”或“过滤”，而是基于有序性、最左前缀和值分布的确定性裁剪。
索引如何实现范围收缩
以B+ Tree索引为例，所有键值按升序物理排列，叶子节点形成双向链表。当执行 WHERE age > 20 AND age 时：
- 优化器定位到 age=20 的右侧第一个叶节点（下界），再定位到 age=30 的左侧第一个叶节点（上界）
- 直接跳过树中所有小于20和大于等于30的分支路径
- 仅遍历这两个边界之间的连续叶节点块——这就是“范围收缩”的实质：从全表扫描 → 全索引扫描 → 索引范围扫描
条件顺序影响收缩效果
复合索引 (city, age, name) 的字段顺序决定了收缩能力：
Find JSON Path Online
下载
Easily find JSON paths within JSON objects using our intuitive Json Path Finder
-
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 部分无法收缩，整体可能放弃索引 - 统计信息过期：优化器误判选择性，认为全表扫描比索引范围扫描更快
