本地索引存在结构性倾斜时，需检查各分区leaf_blocks是否严重不均（最大值超最小值5倍且num_rows同步差异大），确认分区裁剪是否生效（pstart/pstop是否为key），确保组合索引中分区键为最左前缀，并定期用granularity=>'all'刷新统计信息。
查本地索引各分区的叶子块数量是否严重不均
本地索引（LOCAL）每个分区对应一个独立索引段，如果某些分区数据暴涨而其他分区长期空置，会导致执行计划误判——优化器可能认为“走索引快”，但实际只有一两个分区的索引能高效定位，其余分区扫描开销巨大。
用以下语句检查各分区索引的物理结构分布：
SELECT index_name, partition_name, leaf_blocks, num_rows FROM user_ind_partitions WHERE index_name = 'YOUR_LOCAL_INDEX_NAME' ORDER BY leaf_blocks DESC;
如果最大 leaf_blocks 是最小值的 5 倍以上，且 num_rows 差异同步放大，基本可判定存在结构性倾斜。
- 常见诱因：按时间范围分区（如
PARTITION BY RANGE (CREATED)），但业务写入集中在最近 1–2 个分区，老分区几乎无更新，索引块未被回收 - 注意：
leaf_blocks不等于数据量，但和索引键值密度、删除碎片直接相关；单纯看num_rows可能掩盖高碎片问题
确认查询是否真的“走对了分区”
即使执行计划显示用了本地索引，也不代表 Oracle 真的只访问目标分区。尤其当谓词中分区键未提供确定值（比如用了 CREATED > SYSDATE - 30 但没绑定具体日期），优化器可能 fallback 到扫描多个分区索引段。
运行带 DBMS_XPLAN.DISPLAY_CURSOR 的真实执行计划：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ALLSTATS LAST'));
重点看输出里的 PSTART 和 PSTOP 列：
- 若显示
PSTART=KEY且PSTOP=KEY，说明分区裁剪生效 - 若出现
PSTART=1和PSTOP=12（总共有 12 个分区），哪怕你只查最近一天数据，也意味着全分区索引扫描 - 此时要回溯 SQL 中的过滤条件——是否对分区键用了函数、隐式转换或绑定变量类型不匹配？
避免在本地索引上建组合索引时忽略分区键顺序
本地索引的分区键必须是索引字段的最左前缀，否则无法保证分区裁剪与索引查找协同。例如表按 SALES_MONTH 分区，却建了 CREATE INDEX idx ON sales(CUSTOMER_ID, PRODUCT_ID) LOCAL，那即便加了 WHERE SALES_MONTH = '202608'，Oracle 仍可能无法精准定位到该分区的索引段。
正确做法是把分区键放在组合索引最左侧：
CREATE INDEX idx_sales_month_cust ON sales(SALES_MONTH, CUSTOMER_ID) LOCAL;
- 错误顺序不会报错，但执行计划里常出现
ACCESS PREDICATES为空，或仅剩FILTER PREDICATES - 如果业务确实需要高频查
CUSTOMER_ID且不带分区键，考虑补一个全局索引（GLOBAL），但需权衡 DML 开销
统计信息过期会放大本地索引不平衡的影响
本地索引各分区的统计信息（user_ind_partitions 视图中的 num_rows, clustering_factor）一旦过期，优化器就无法判断哪个分区索引更“健康”。它可能选中一个 leaf_blocks 高但 clustering_factor 差的老分区索引，导致大量随机 I/O。
强制刷新特定本地索引所有分区的统计信息：
EXEC DBMS_STATS.GATHER_INDEX_STATS(ownname => 'SCHEMA_NAME', indname => 'YOUR_LOCAL_INDEX_NAME', granularity => 'ALL');
- 别用
granularity => 'AUTO'—— 在严重倾斜场景下，Oracle 常漏掉低数据量分区 - 执行后立刻查
user_ind_partitions，确认last_analyzed时间已更新，且clustering_factor值合理（越接近num_rows越差）
真正麻烦的是那些跨年分区的老索引——碎片多、键值稀疏、统计信息常年不更新，光重建索引不够，得配合分区维护（如 ALTER INDEX ... REBUILD PARTITION）和定期分析。
