根本原因是查询未触发分区裁剪，反而因全局索引随机I/O、本地索引未对齐或统计信息陈旧导致执行计划劣化；需检查执行计划PARTITION START/STOP、索引分区定义及统计信息 freshness。
分区表查询比全表扫描还慢，根本原因不是分区本身拖慢了速度，而是查询实际没走分区裁剪，反而因额外的索引跳转、跨分区i/o或错误的执行路径引入了更多开销。
查询没触发分区裁剪，却走了全局索引扫描
当WHERE条件中对分区键用了函数（比如TRUNC(order_date)）或隐式类型转换（比如把CHAR型分区键和DATE字面量比较），Oracle就无法推导出目标分区范围，被迫放弃分区裁剪。此时如果建了全局索引，优化器可能选INDEX RANGE SCAN + TABLE ACCESS BY INDEX ROWID，但因为ROWID指向的是分散在多个物理段的数据块，随机I/O暴增，比顺序读全表还慢。
- 用
EXPLAIN PLAN FOR查执行计划，确认PARTITION START和PARTITION STOP是否为KEY或具体分区名；若显示ALL，说明裁剪失效 - 检查谓词是否直接引用分区键列，避免
TO_CHAR(partition_key)、NVL(partition_key, ...)等干扰 - 全局索引在非分区键查询时有用，但在分区键过滤场景下，优先用本地索引+裁剪，别为了“有索引”而建全局索引
本地索引未对齐分区边界，导致跨分区回表
本地索引（LOCAL）必须与基表分区策略严格一致。如果基表按RANGE (TRUNC(sales_date, 'MM'))分区，而本地索引建在sales_date列上且没指定PARTITION BY RANGE (TRUNC(sales_date, 'MM'))，Oracle可能在索引扫描后，需要跨多个分区回表取数据——一次逻辑读变成多次随机I/O。
- 用
SELECT * FROM USER_IND_PARTITIONS WHERE INDEX_NAME = 'YOUR_IDX'核对每个索引分区的HIGH_VALUE是否与基表USER_TAB_PARTITIONS一致 - 建本地索引时显式声明分区方式：
CREATE INDEX idx_mv_dt ON mv_sales(sales_date) LOCAL PARTITION BY RANGE (TRUNC(sales_date, 'MM')) - 若基表用表达式分区，索引也得用相同表达式，不能只靠列名匹配
统计信息陈旧或缺失，优化器误选嵌套循环连接
物化视图或分区表的统计信息过期时，优化器会低估分区数据量，以为某个小分区里有几十行，结果选了NESTED LOOPS去驱动它跟大表JOIN——实际该分区有百万行，每轮循环都触发大量物理读。
- 刷新前先确认：
SELECT STALE_STATS FROM USER_TAB_STATISTICS WHERE TABLE_NAME = 'YOUR_TABLE'，YES即需重收集 - 对分区表，用
DBMS_STATS.GATHER_TABLE_STATS并设GRANULARITY => 'AUTO'，让Oracle自动按分区粒度收集 - 避免只收集表级统计而忽略索引：
ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE比固定百分比更稳
真正卡住性能的，往往不是“有没有分区”，而是分区结构、索引定义、统计信息这三者之间有没有对齐。哪怕只差一个TRUNC()或一行GRANULARITY参数，执行计划就可能从分钟级掉到秒级，也可能反过来。动手前先看PLAN，再比USER_TAB_PARTITIONS和USER_IND_PARTITIONS，别信“建了索引就快”的直觉。
