DB2 AS400 7.3分区表查询未仅访问指定分区的执行计划问题

问题背景 #

系统运行DB2 for i（AS400）7.3版本，因数据量持续增长为部分表启用表分区功能。现有一张约5000万条记录的表，按YEAR列（范围2020-2024）做范围分区，每个分区约1000万条数据，已通过QSYS2.SYSPARTITIONSTAT表确认分区创建正常、数据量符合预期。

执行最简测试查询：

select * from dbschema.PARTITIONED_TABLE where YEAR = 2023;

预期查询仅访问YEAR=2023对应的分区，但通过System i Navigator的Run and Explain生成的执行计划显示，SQE执行了全表扫描，访问了表的所有成员（Member of table being queried - *ALL）。

疑问解答与优化方案 #

1. 是否遗漏相关配置？ #

• 检查分区键数据类型匹配：确保WHERE子句中YEAR值的类型与表定义的YEAR列类型完全一致（例如列是整数类型，就不要用字符串'2023'作为查询条件），类型不匹配会直接导致分区剪枝失效。
• 验证分区策略与规则：通过DSPFD FILE(dbschema/PARTITIONED_TABLE)命令查看分区定义，确认RANGE(YEAR)的区间准确覆盖2020-2024，且各分区边界无重叠。
• 确认查询优化级别：DB2 for i 7.3默认支持分区剪枝，但需确保未禁用SQE优化。可通过DSPQRYA命令查看当前查询优化级别，建议设置为*OPTIMIZE或更高。

2. DB2 AS400是否具备跳过不符合条件分区的机制？ #

DB2 for i 7.3完全支持分区剪枝（Partition Pruning），能够自动跳过不满足WHERE条件的分区。但剪枝生效需满足以下前提：

• 查询条件必须直接引用分区键列，且为简单的等值或范围判断（不能嵌套函数，例如YEAR(DATE_COL) = 2023若DATE_COL不是分区键，则无法触发剪枝）。
• 分区键列无隐式类型转换，否则优化器无法识别分区匹配规则。

3. 如何查看查询实际访问的分区？ #

• 查询系统表QSYS2.PARTITION_SCAN_INFO：执行目标查询后，该表会记录最近查询访问的分区信息，执行以下语句即可查看：

SELECT TABLE_SCHEMA, TABLE_NAME, PARTITION_NUMBER, PARTITION_NAME
FROM QSYS2.PARTITION_SCAN_INFO
WHERE TABLE_SCHEMA = 'DBSCHEMA' AND TABLE_NAME = 'PARTITIONED_TABLE';

• 调试或锁信息验证：通过STRDBG启动调试，执行查询后查看访问的表成员（分区对应表成员）；或使用WRKOBJLCK查看表成员的锁信息，间接判断实际访问的分区。

额外优化建议 #

• 更新统计信息：运行RUNSTATS ON TABLE dbschema.PARTITIONED_TABLE AND INDEXES ALL命令更新表与索引的统计信息，优化器依赖统计信息判断分区剪枝的收益。
• 避免全列查询：不要使用SELECT *，仅查询需要的列，减少数据传输量的同时，帮助优化器更精准地生成执行计划。
• 强制分区剪枝提示：若剪枝仍不生效，可在查询中添加OPTIMIZE FOR PARTITION PRUNING提示强制优化器启用分区剪枝：

select * from dbschema.PARTITIONED_TABLE where YEAR = 2023 OPTIMIZE FOR PARTITION PRUNING;

内容的提问来源于stack exchange，提问作者Michał