本地索引必须将分区键置于前导列（column_position 1–2），否则可能导致全表扫描或ORA-01502错误；需结合USER_IND_COLUMNS验证列序，而非仅看STATUS='VALID'。
查 USER_IND_COLUMNS 确认本地索引是否覆盖分区键
本地索引必须包含分区键字段，否则 dml 或查询可能意外走全表扫描，甚至触发 ora-01502（索引不可用）错误。很多人只看 status = 'valid' 就以为没问题，其实索引列顺序、是否缺失分区键才是关键。
- 执行
SELECT index_name, column_name, column_position FROM USER_IND_COLUMNS WHERE index_name = '<code>YOUR_LOCAL_INDEX' ORDER BY column_position;，检查第一列或前几列是否为分区键字段（比如CREATED_DATE或REGION_ID） - 如果分区键字段不在
column_position1–2 位，且索引又没加GLOBAL，那它大概率无法剪枝——哪怕状态是 VALID - 特别注意组合分区（如
RANGE-LIST），需同时匹配一级和二级分区键字段
用 DBMS_STATS.LOCK_TABLE_STATS 防止统计信息过期导致执行计划错乱
分区表一旦新增分区但没及时收集统计信息，优化器可能误判数据分布，让本该走本地索引的 SQL 走了全分区扫描。而 LOCK_TABLE_STATS 不是“锁住不更新”，而是防止自动任务或误操作覆盖关键分区的统计值。
- 对刚完成数据加载的分区，先运行
DBMS_STATS.GATHER_TABLE_STATS指定partname => 'P202404' - 立刻执行
DBMS_STATS.LOCK_TABLE_STATS锁定该分区（注意：Oracle 12c+ 支持按分区锁定，旧版本只能锁整表） - 验证是否生效：
SELECT stattype_locked FROM USER_TAB_STATISTICS WHERE table_name = 'YOUR_TABLE' AND partition_name = 'P202404';返回ALL才算成功
检查无主键全局索引时，重点盯 UNIQUENESS 和 JOIN 场景下的失效风险
没有主键的全局索引（尤其是 UNIQUE 类型）在分区 DDL（如 ALTER TABLE ... DROP PARTITION）后容易变成 UNUSABLE，但状态未必立刻变红——它可能仍显示 VALID，直到第一次被用于唯一性校验或 JOIN 时才报错。
- 查状态不能只看
USER_INDEXES.STATUS，要连带查USER_INDEXES.DOMAIN_INDEX_STATUS和USER_INDEXES.DROPPED - 更可靠的方式是强制触发一次索引访问：
SELECT /*+ INDEX(t idx_global_no_pk) */ COUNT(*) FROM your_table t WHERE indexed_col = 'x';，观察是否报ORA-01502 - 如果业务 SQL 常走
JOIN且依赖该索引去重，务必在每次分区维护后补一句ALTER INDEX idx_global_no_pk REBUILD ONLINE;
用 DBMS_PARTITION.VERIFY_PARTITION 快速比对分区键值范围与实际数据
这是 Oracle 19c+ 提供的轻量级完整性校验工具，比全表 COUNT(*) 或手动 MIN/MAX 更准——它会真正读取每个分区的高水位和元数据边界，发现“数据写入了错误分区”这类静默错误。
- 调用前确保目标分区没被并发 DML 锁死，否则会返回
ORA-00054 - 示例：
DECLARE ret BOOLEAN; BEGIN ret := DBMS_PARTITION.VERIFY_PARTITION('YOUR_TABLE', 'P202404'); END;，返回FALSE表示键值越界（比如P202404定义为VALUES LESS THAN (DATE '2024-05-01')，但里面有2024-05-03的记录） - 它不修复，只报警；发现异常后得用
EXCHANGE PARTITION或INSERT /*+ APPEND */重新归位
最常被跳过的一步，是验证本地索引列顺序是否真能支撑分区剪枝——不是“有索引”就行，是“索引前导列=分区键”才行。这点在跨版本迁移或接手别人建的表时，几乎必踩坑。
