SQL报表跨分区统计慢的核心原因是未触发分区裁剪，需通过EXPLAIN检查Partitions accessed和谓词条件，确保分区键设计匹配查询模式且SQL写法不破坏裁剪逻辑。

SQL报表跨分区统计慢，核心问题往往不是SQL本身写得差，而是数据库没用上分区裁剪（Partition Pruning）——该跳过的分区一个没跳，全表扫描式扫描几十个分区，性能自然崩了。

确认是否真触发了分区裁剪

别凭感觉判断，必须看执行计划。在MySQL 8.0+、Oracle、PostgreSQL（带分区扩展）或TiDB中，执行EXPLAIN或EXPLAIN ANALYZE，重点检查：

• Partitions accessed 字段：显示实际访问的分区名（如 p202401, p202402），若出现 all 或范围过大（如 p202301..p202412），说明裁剪失效
• Filter 或 Predicate Information 中是否包含分区键的等值/范围条件，且未被函数包裹（如 WHERE DATE_SUB(create_time, INTERVAL 1 DAY) = '2024-03-01' 就会禁用裁剪）

分区键设计要匹配查询模式

常见误区是“按时间建了分区就万事大吉”，但报表常查的是“近7天”“上个月”“某业务线+某时间段”，这时单一分区键不够用：

• 若高频过滤字段是 tenant_id 和 create_time，建议用 LIST-RANGE 组合分区（MySQL 8.5+支持）或按 tenant_id % 16 + 时间做二级分区
• 避免用非确定性函数作分区键，如 TO_DAYS(NOW())；改用 TO_DAYS(create_time) 并确保查询条件能对齐
• 日期字段务必用 DATE 或 DATETIME 类型，别存成字符串（'20240301'），否则无法走范围裁剪

SQL写法必须“友好”，不破坏裁剪逻辑

再好的分区设计，一句错误写法就能让裁剪失效：

• ✅ 正确：WHERE create_time >= '2024-03-01' AND create_time
• ❌ 错误：WHERE DATE(create_time) = '2024-03-15'（对字段加函数）
• ❌ 错误：WHERE create_time BETWEEN STR_TO_DATE('20240301', '%Y%m%d') AND ...（右侧也用了函数）
• ⚠️ 注意隐式类型转换：WHERE create_time = '2024-03-01' 在某些版本可能转成 DATE 比较，丢失时分秒导致索引/分区失效，统一用 >=/

补充手段：小表驱动 + 分区表联查优化

当报表需关联多张分区表（如订单+订单明细），即使单表裁剪生效，嵌套循环也可能反复打开同一分区：

• 优先用 IN (子查询) 或 JOIN 时确保驱动表结果集小，并在被驱动表的分区键上有等值条件
• 考虑物化中间结果：先将筛选后的主表ID存入临时表（带索引），再用该临时表驱动关联，避免重复分区扫描
• 部分引擎（如TiDB）支持 PARTITION SELECTION hint，可强制指定分区，但属兜底方案，不推荐长期依赖