SQL分区表查询不走分区主因是查询条件未匹配分区键规则：分区键须直接出现在WHERE中且不可被函数包裹，类型与格式须严格一致，避免隐式转换、子查询及复杂表达式导致裁剪失效。
SQL分区表查询不走分区，通常不是分区本身有问题，而是查询条件没“对上”分区键的规则。核心就一点：查询谓词必须能被优化器静态推导出只涉及特定分区，否则就会全分区扫描甚至全表扫描。
分区键必须出现在WHERE条件中，且不能被函数/表达式包裹
这是最常见踩坑点。即使你查的是按 dt（字符串日期）分区的表，写成 WHERE to_date(dt) = '2024-01-01' 或 WHERE dt || '' = '20240101'，优化器无法确定具体分区，直接放弃分区裁剪。
- ✅ 正确写法：
WHERE dt = '20240101'（与分区字段类型、格式完全一致） - ✅ 日期范围也行：
WHERE dt BETWEEN '20240101' AND '20240131' - ❌ 错误写法：
WHERE substr(dt, 1, 6) = '202401'、WHERE DATE(dt) = '2024-01-01'、WHERE dt IN (SELECT ...)
避免隐式类型转换，确保字段和值类型严格匹配
比如分区字段是 STRING 类型，但传入的是整数或带引号不一致的格式，如 WHERE dt = 20240101（无引号），Hive/Spark SQL 会触发隐式转换，导致分区裁剪失效。
- 检查字段类型：
DESCRIBE FORMATTED table_name确认分区字段类型 - 字符串分区务必加单引号：
WHERE dt = '20240101' - 数值型分区（少见但存在）则不加引号，且不能补零：
WHERE pt = 20240101，而非pt = '020240101'
IN 列表和动态参数需谨慎，长度与写法影响裁剪能力
IN 条件可以走分区裁剪，但有前提：列表必须是常量、长度不宜过大（一般建议 ≤ 1000 项），且不能含子查询或变量。
- ✅ 安全写法：
WHERE dt IN ('20240101', '20240102', '20240103') - ⚠️ 风险写法：
WHERE dt IN (SELECT DISTINCT dt FROM tmp_days)→ 不裁剪 - ⚠️ 大列表隐患：
IN (...5000个值...)可能触发优化器降级，改用临时表 + JOIN 更稳
分区字段参与JOIN或子查询时，裁剪常失效
如果分区条件藏在子查询里，或作为JOIN的非驱动表条件，优化器很难下推分区过滤。例如：
- ❌
SELECT * FROM t1 JOIN (SELECT dt FROM dim_date WHERE month='202401') d ON t1.dt = d.dt - ✅ 改为显式过滤：
SELECT * FROM t1 JOIN dim_date d ON t1.dt = d.dt WHERE t1.dt LIKE '202401%'，并确保t1.dt在主查询 WHERE 中出现 - ✅ 更可靠方式：先用分区条件过滤大表，再 JOIN：
SELECT * FROM (SELECT * FROM t1 WHERE dt >= '20240101' AND dt
不复杂但容易忽略——分区表不是建了就自动加速，关键在查询怎么写。盯住执行计划里的 Partition Filters 或 Partitions read 字段，一眼就能验证是否真正走了分区裁剪。
