索引区间裁剪是数据库优化器利用B+树索引快速定位范围查询叶节点区间的底层机制；需建有序btree索引、避免函数/类型转换、组合查询等值列前置，并通过执行计划验证range扫描是否生效。
范围查询（如 BETWEEN、>=、）在SQL中很常见，但若缺乏合适索引或索引未被有效利用，容易导致全表扫描。索引区间裁剪（Index Range Scanning / Range Predicate Pushdown）是数据库优化器基于索引结构快速定位满足条件的叶节点区间的过程——它不是手动操作，而是依赖索引设计与查询写法共同触发的底层行为。
确保查询字段上有合适的有序索引
只有B+树索引（如MySQL的普通索引、PostgreSQL的btree索引）才支持高效区间裁剪。哈希索引、全文索引或无序索引（如某些NoSQL的默认索引）不适用。
- 单列范围查询（如
WHERE create_time BETWEEN '2024-01-01' AND '2024-06-30'）应为该列单独建btree索引 - 多条件组合查询（如
WHERE status = 'active' AND updated_at > '2024-05-01'）建议创建联合索引，把等值列放前，范围列放后：(status, updated_at) - 避免在索引列上使用函数或表达式（如
WHERE YEAR(created_at) = 2024），这会中断区间裁剪，改用created_at >= '2024-01-01' AND created_at
理解并验证执行计划中的“range”类型
数据库是否真正启用区间裁剪，需通过执行计划确认。关键看 type（MySQL）或 Node Type（PostgreSQL）是否为 range 或 Index Scan 并带明确的 Index Cond。
- MySQL：用
EXPLAIN SELECT ...，观察type列为range，且key显示实际使用的索引，rows显著小于总行数 - PostgreSQL：用
EXPLAIN (ANALYZE, BUFFERS) SELECT ...，确认出现Index Scan而非Seq Scan，并查看Index Cond是否精确反映查询边界 - 若出现
type: index（MySQL）或Index Only Scan但过滤条件未生效，可能是索引覆盖不足或统计信息过期，需ANALYZE table
避免隐式类型转换破坏索引有效性
当查询条件与索引列类型不一致时（如字符串列用数字比较、带时区时间与无时区时间混用），数据库可能隐式转换字段值而非参数，导致无法使用索引进行区间裁剪。
- 检查列定义：
DESCRIBE orders或\d orders，确认order_no是VARCHAR还是BIGINT - 查询时保持类型一致：若
order_no是字符串，写WHERE order_no >= 'ORD20240001'，而非>= 20240001 - 时间字段统一时区：用
updated_at >= '2024-05-01T00:00:00+08'匹配TIMESTAMP WITH TIME ZONE列
控制范围大小，警惕“宽区间”退化为扫描
即使有索引，过大的范围（如 WHERE id > 10 在主键索引上）仍可能让优化器放弃区间裁剪，转而选择全索引扫描甚至全表扫描——尤其当满足条件的数据占比超过约15%~20%时。
- 用
COUNT(*)估算匹配比例：SELECT COUNT(*) FROM t WHERE status = 'pending'/SELECT COUNT(*) FROM t - 对高频宽范围场景，考虑增加过滤性更强的前置条件（如加时间分区、状态分组）或引入物化视图/汇总表
- 必要时用
FORCE INDEX（MySQL）或/*+ IndexScan(t idx_name) */（PG via extensions）引导，但需配合监控，避免掩盖真实问题
