分区键必须被查询条件直接等值或范围比较才能有效利用Range分区性能优势，否则将退化为全分区扫描；统计信息需及时更新并指定GRANULARITY=>'ALL'以确保分区剪裁准确。
分区键是否被查询条件有效利用
range 分区的性能优势完全依赖于查询能否触发 partition pruning（分区剪裁）。如果 where 条件里没用到分区键，或者用了函数、类型转换、模糊匹配（如 like '%2025%'），oracle 就无法跳过无关分区，退化为全分区扫描。
常见错误现象：执行计划中出现 ACCESS BY GLOBAL INDEX ROWID 或 ALL PARTITIONS；EXPLAIN PLAN 显示 partition start: 1, partition stop: ALL。
- 确保查询条件直接等值或范围比较分区键字段，例如
WHERE trade_date >= DATE '2025-01-01' AND trade_date - 避免对分区键做函数操作：
TO_CHAR(trade_date, 'YYYY-MM')会失效剪裁；改用trade_date BETWEEN ... AND ... - 分区键字段类型必须与查询条件一致——比如分区键是
DATE类型，就别用字符串'2025-01-01'直接比较，应显式转成DATE或用日期字面量
本地索引 vs 全局索引怎么选
本地索引（LOCAL）和全局索引（GLOBAL）在 Range 分区场景下行为差异极大，选错会导致索引失效或维护成本飙升。
本地索引按分区一一对应，每个分区有自己的索引段；全局索引跨所有分区，结构统一但 DDL 操作（如 ALTER TABLE ... DROP PARTITION）需重建索引，停写时间长。
- 高频单分区查询（如查某月数据）+ 频繁增删分区 → 优先用
CREATE INDEX idx_local ON t(col) LOCAL - 跨分区查询多（如查某用户全量流水）+ 分区极少变动 → 可考虑全局索引，但必须加
UNUSABLE后重建逻辑，否则DROP PARTITION会让全局索引失效 - 切忌在本地索引上建
UNIQUE约束——除非分区键也参与唯一约束定义，否则 Oracle 不允许
分页查询为何越往后越慢
千万级数据下用 ROWNUM 嵌套分页（如 WHERE ROWNUM ）本质是先取满前 N 行再过滤，N 越大，扫描行数指数级增长。这不是“慢”，是设计缺陷。
典型低效写法：SELECT * FROM (SELECT a.*, ROWNUM r FROM (SELECT * FROM t ORDER BY id) a) WHERE r BETWEEN 10001 AND 10010 —— 内层子查询仍要扫至少 10010 行。
- 真正有效的方案是“基于主键/索引字段的游标分页”：记录上一页最后的
id值，下一页用WHERE id > last_id ORDER BY id FETCH FIRST 10 ROWS ONLY（Oracle 12c+） - 若必须用 ROWNUM，至少把范围限制压进内层：
SELECT * FROM (SELECT /*+ INDEX(t idx_trade_date) */ *, ROWNUM rn FROM t WHERE trade_date >= DATE'2025-01-01' AND ROWNUM 10000 - 永远不要在无索引字段上分页，尤其别在
TEXT或LOB列上ORDER BY
统计信息是否及时更新
Oracle 优化器靠统计信息决定是否走分区剪裁、用哪个索引、是否并行。千万级表一旦数据批量导入或分区变更，旧统计信息会让执行计划严重失真——比如该走索引却选了全表扫描，该剪裁 1 个分区却扫了 12 个。
常见陷阱：用 DBMS_STATS.GATHER_TABLE_STATS 时没加 GRANULARITY => 'ALL'，导致只收集了表级统计，漏掉各分区的行数、高/低值等关键信息。
- 每次新增分区后，立即执行：
DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'TABLE_NAME', GRANULARITY => 'ALL') - 避免用
ESTIMATE_PERCENT => 1这类极低采样率——千万级表建议至少10，或直接DBMS_STATS.AUTO_SAMPLE_SIZE - 检查是否启用自动收集：
SELECT client_name, status FROM dba_autotask_client WHERE client_name LIKE '%stats%'；生产环境建议关掉自动任务，改用窗口期手动触发
真实场景里最常被忽略的不是语法或索引，而是分区键和业务查询模式是否真正对齐——比如用 CREATE_TIME 分区，但 90% 查询却是按 USER_ID + 时间范围，这就注定剪裁失效。这时候要么加复合分区，要么补位图索引，而不是反复调优单一分区策略。
