SQL分区表的分区裁剪（prune）是指查询执行时只扫描符合查询条件的分区，跳过无关分区，从而减少数据扫描量提升查询效率。但实际场景中常出现prune未生效的问题，导致查询扫描全部分区，性能远不及预期。
分区表prune未生效的常见原因
1. 查询条件未使用分区键
分区裁剪的核心依据是查询条件中包含分区键，如果查询条件完全不涉及分区键，数据库无法判断需要扫描哪些分区，就会默认扫描全部分区。比如按create_time范围分区的表，查询条件只用到了user_id而没有create_time相关条件，就无法触发裁剪。
2. 分区键上使用了函数或表达式
如果对分区键做了函数处理或者参与了表达式计算，数据库无法直接将条件映射到分区范围，也会导致prune失效。例如分区键是order_date，查询条件写成DATE(order_date) = '2024-05-01'，就会让分区裁剪失效。
3. 分区键条件为范围外或无法确定的值
当查询条件中的分区键范围超出了所有分区的覆盖范围，或者条件值是动态的无法在优化阶段确定，比如使用了变量、子查询返回不确定值，数据库无法提前判断匹配的分区，也会跳过裁剪逻辑。
4. 分区表类型不支持对应条件的裁剪
不同的分区类型支持的裁剪条件不同，比如哈希分区通常只支持等值条件的裁剪，如果使用范围条件查询哈希分区表，就无法触发prune。还有列表分区如果条件值不在任何分区的枚举列表中，也会扫描全部分区。
5. 数据库版本或配置问题
部分低版本的数据库对分区裁剪的支持不完善，或者相关优化参数被关闭，也会导致prune功能不生效。比如MySQL早期版本对分区裁剪的支持存在较多限制，需要确认版本和optimizer_switch中的分区相关开关是否开启。
用explain检查分区裁剪的要点
1. 查看partitions字段
执行EXPLAIN语句后，结果中的partitions字段会显示查询将要扫描的分区名称。如果prune生效，该字段只会显示匹配条件的分区；如果显示全部分区名称或者NULL（全表扫描），则说明裁剪未生效。
以下是MySQL中explain查看分区裁剪的示例：
-- 创建按create_time范围分区的表
CREATE TABLE order_info (
id INT,
user_id INT,
create_time DATE
)
PARTITION BY RANGE (YEAR(create_time)) (
PARTITION p2022 VALUES LESS THAN (2023),
PARTITION p2023 VALUES LESS THAN (2024),
PARTITION p2024 VALUES LESS THAN (2025)
);
-- 生效的裁剪查询
EXPLAIN SELECT * FROM order_info WHERE create_time >= '2023-01-01' AND create_time < '2024-01-01';
-- 此时partitions字段会显示p2023
-- 未生效的裁剪查询（分区键使用函数）
EXPLAIN SELECT * FROM order_info WHERE YEAR(create_time) = 2023;
-- 此时partitions字段会显示p2022,p2023,p2024
2. 确认type字段的访问类型
如果type字段显示为ALL，说明是全表扫描，大概率分区裁剪未生效；如果显示为range、ref等更优的访问类型，且partitions字段只显示部分分区，说明裁剪生效。
3. 检查possible_keys和key字段
如果查询条件中分区键上有索引，possible_keys会显示相关索引，key字段会显示实际使用的索引，结合partitions字段可以确认是否同时用到了索引和分区裁剪。如果key为NULL且partitions为全部分区，说明既没有走索引也没有触发裁剪。
4. 注意不同数据库的差异
不同数据库的explain输出格式略有不同，比如PostgreSQL的EXPLAIN会直接显示Partition相关的扫描信息，Oracle的EXPLAIN PLAN会在PARTITION_START、PARTITION_STOP字段显示分区的起止信息，需要结合对应数据库的文档解读输出结果。
优化建议
如果检查到prune未生效，首先调整查询条件，确保直接使用分区键不做额外处理；其次确认分区类型匹配查询条件类型；最后检查数据库版本和配置，必要时升级版本或开启相关优化参数。定期用explain检查分区表的查询计划，能提前发现裁剪失效的问题，避免性能隐患。