跨分区查询变慢的根本原因是优化器需为每个相关分区生成执行计划分支，分区数超1024后元数据遍历开销剧增，导致parse cpu飙升、library cache lock等待增多，即使只查少量分区也会扫描全部分区元数据。
为什么跨分区查询会变慢，而不是“自动加速”
分区表不是万能加速器——跨分区查询（比如查某用户全量流水、查多个时间段汇总）反而可能比非分区表更慢。根本原因在于：优化器必须为每个涉及的分区生成执行计划分支，分区数越多，硬解析开销越大。Oracle 19c 中，分区数超 1024 后，PARSE CPU 显著飙升，library cache lock 等待增多，哪怕只查两个分区，也可能扫描全部分区元数据。
确认是否真被分区数量拖慢解析
别急着删分区或改表结构，先验证瓶颈是否在解析阶段：
- 查当前会话等待：
SELECT event, p1text, p1 FROM v$session_wait WHERE sid = <your_sid> AND event LIKE 'library%'</your_sid>，若出现library cache lock或library cache pin，高度可疑 - 对比执行计划：先跑
EXPLAIN PLAN FOR SELECT ...，再加/*+ NO_EXPAND */hint 重跑，若后者解析快 5 倍以上，基本锁定是谓词展开开销 - 查分区总数：
SELECT COUNT(*) FROM dba_tab_partitions WHERE table_name = 'YOUR_TABLE'，超过 2048 是高风险阈值
不改表结构、不删分区的快速缓解方案
针对已上线、无法停机的系统，优先用这三种低成本手段：
- 对明确知道范围的查询，强制关闭分区扩展：
SELECT /*+ NO_EXPAND */ * FROM t WHERE user_id = 123 AND dt BETWEEN DATE '2024-01-01' AND DATE '2024-06-30'。注意：仅适用于 WHERE 中含分区键且范围可控的场景 - 把字面量改成绑定变量，并确保类型严格匹配：
WHERE dt BETWEEN :start_dt AND :end_dt，且:start_dt必须是DATE类型（不是TIMESTAMP），否则隐式转换会中断分区裁剪链 - 高频跨分区聚合类查询（如日报、月报），直接建物化视图：
CREATE MATERIALIZED VIEW mv_user_summary REFRESH FAST ON COMMIT AS SELECT user_id, TRUNC(dt, 'MM') mon, SUM(amount) amt FROM t GROUP BY user_id, TRUNC(dt, 'MM')，让应用查 MV 而非原始表
本地索引 vs 全局索引：跨分区查询时怎么选
本地索引（CREATE INDEX idx ON t(col) LOCAL）虽不能跨分区跳转，但配合物化视图或业务层分拆查询，实际更稳；全局索引（GLOBAL）看似支持任意字段查询，但代价极高：
-
DROP PARTITION会让全局索引失效，必须加UNUSABLE后重建，期间 DML 被阻塞 - UPDATE/DELETE 涉及分区键时，可能触发所有分区索引段的更新，I/O 放大明显
- 统计信息维护成本高，
DBMS_STATS.GATHER_TABLE_STATS默认不收集全局索引分区级统计
真正难处理的从来不是“查得慢”，而是“每次解析都卡住”——尤其在 RAC 环境下，元数据同步放大延迟。动手前务必用 10046 trace 抓 parse 阶段调用栈，确认是不是在遍历 dba_tab_partitions 上花了 90% 时间。
