明明过滤了，为什么还是读了这么多数据？
从 Partition Pruning 到小文件和日期分区倾斜，分开判断“读哪些”和“怎样读”。
最近 30 天的特征查询仍然读得很重
明明过滤了，为什么还是读了这么多数据？
Transaction 已经按 txn_date 分区，需求也只要固定最近 30 天。页面先把 3 年历史和 30 天分区放在一起，再把分区内的大量小文件单独拿出来比较。
过滤条件写在查询里以后，怎样确认它真的减少了读取范围？
核心概念
Partition Pruning：只读取需要的分区
Partition Pruning 利用过滤条件排除不需要的分区，减少 Scan 范围；它不会自动把命中分区里的碎片文件整理好，也不会消除真实业务高峰造成的大分区。
先确认过滤条件有没有在分区层生效
最近 30 天交易对手数是一个固定窗口需求。理想的读取范围是：3 年历史中只命中最近 30 天的 txn_date 分区。判断时要同时看命中分区数、Scan Bytes、文件数和相对耗时，而不是只看 SQL 文本里有没有日期条件。
本节所有 Scan Bytes、文件数和耗时都是 relative simulation / 教学模拟值。它们用来比较同一任务的两种读取范围，不是任何真实银行集群的 benchmark。
- 3 年历史 → 最近 30 天分区，是读取范围的变化。
- Scan Bytes 下降，才说明实际读取量确实缩小。
- 7 天、90 天可以采用同类固定窗口；本节不分别做完整 Demo。
11-2 · Partition Pruning 实验
切换扫描范围，再打开文件布局
先比较 3 年历史与最近 30 天的命中分区，再保持范围不变，观察碎片小文件与 Compaction 后布局的差异。最后切换到双 11，判断日期分区倾斜发生在哪一层。
正在加载交互实验…
放在一起看
两个动作解决的不是同一个问题
它们都可能让后续读取变快，但收益和写入代价要分别记录。
缩小读取范围
- 排除不需要的 txn_date 分区
- 减少 Scan Bytes 和命中分区数
- 依赖过滤条件与分区字段语义正确
整理命中分区内的文件
- 减少碎片小文件的打开与调度
- 改善同一范围的物理读取组织
- 新增写入、存储和维护工作
先接受业务分布事实
- 普通日期 100~150 GB
- 双 11 可能达到 1.8 TB
- 继续考虑大分区的并行与拆分方式