partition by本身不触发全表扫描，而是其搭配的order by和窗口函数迫使oracle对整个分区排序或累积计算；若分区键无索引或分区粒度太粗导致剪枝失效，优化器便退化为全表扫描。
为什么PARTITION BY会触发全表扫描
不是 PARTITION BY 本身导致扫描，而是它常搭配的 ORDER BY 和窗口函数（如 ROW_NUMBER()、RANK()）迫使 Oracle 必须先对整个分区数据排序或累积计算。如果分区键上没索引、或分区粒度太粗（比如按年分区但查询跨三年），优化器就放弃剪枝，退化为全表扫描。
检查执行计划里是否真有“WINDOW SORT”或“SORT ORDER BY”
运行 EXPLAIN PLAN FOR 后查 PLAN_TABLE，重点看这两项：
-
Operation列出现WINDOW SORT PUSHED RANK或SORT ORDER BY—— 表示必须排序，内存/临时表空间压力大 -
Rows列显示远高于实际返回行数（比如扫了 3000 万行只返回 5400 行）—— 典型剪枝失效 -
Partition Start/Stop是KEY或ALL而非具体分区名 —— 分区裁剪没生效
真正有效的三类收敛手段
别只盯着 SQL 写法，得从数据分布、索引、分区设计三处下手：
- 在
PARTITION BY+ORDER BY的组合列上建**复合索引**，顺序必须严格匹配：先分区键，再排序键。例如ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY hire_date DESC)，对应索引应为CREATE INDEX idx_dept_hire ON emp(dept_id, hire_date DESC) - 把大分区表改成**更细粒度的分区策略**。比如原按年分区（
PARTITION BY RANGE(year)），但业务总查最近 90 天数据，那就改用按月或按周分区，并确保查询条件能精确命中 1–2 个分区 - 用
WHERE提前过滤，避免窗口函数作用于全量数据。例如不要写SELECT * FROM (SELECT ..., ROW_NUMBER() OVER (...) rn FROM t) WHERE rn = 1，而是先加WHERE status = 'ACTIVE'再开窗
容易被忽略的隐性成本点
即使执行计划看起来“只扫一个分区”，OVER 子句仍可能引发大量临时段读写：排序过程若超出 PGA_AGGREGATE_TARGET，就会 spill 到磁盘（Temp Space 显著增长）。这时光看逻辑读没用，得盯 V$SQL_WORKAREA 里的 TEMPSEG_SIZE 和 MAX_TEMPSEG_SIZE —— 这才是真实瓶颈所在。
