复合分区表的GLOBAL_STATS常为NO，因Oracle要求全局统计必须覆盖所有子分区才可信；仅收集部分子分区或一级分区时，即使执行gather操作，GLOBAL_STATS仍标记为NO，导致优化器无法信任全局行数等指标。
复合分区表的 GLOBAL_STATS 字段为什么常为 NO
Oracle 对复合分区表（如 RANGE-LIST、RANGE-HASH）的统计信息有效性判断，和普通分区表不同。关键点在于：GLOBAL_STATS 字段是否为 'YES'，直接决定优化器能否信任全局行数、平均行长等指标用于跨分区估算。
即使你对每个一级分区都执行了 DBMS_STATS.GATHER_TABLE_STATS，只要没显式触发全局统计重算，GLOBAL_STATS 就仍为 'NO' —— 这不是 bug，是 Oracle 的设计逻辑：它认为“只扫过子分区”不等于“已掌握整张表的数据分布”。
- 查证方式：
SELECT global_stats, num_rows, last_analyzed FROM dba_tables WHERE table_name = 'YOUR_TABLE' - 复合表中，
GRANULARITY => 'PARTITION'实际作用粒度是子分区（SUBPARTITION），不是你看到的PARTITION_NAME -
CASCADE => TRUE（默认）会顺带收集子分区索引统计，但不会自动补全缺失的全局统计
Stale 状态如何让跨分区查询误判行数
当 STALE_STATS = 'YES' 且 GLOBAL_STATS = 'NO' 同时存在时，优化器在估算跨多个分区的谓词（例如 WHERE create_time BETWEEN DATE'2026-01-01' AND DATE'2026-06-30'）时，会退回到硬编码的启发式规则：比如按表块数 × 平均行长粗略推算，或直接假设选择率 5%～10%，导致严重低估/高估。
典型现象是执行计划里 ROWS 列显示几百，实际返回几百万；或者本该走索引范围扫描，却选了全分区扫描。
- 不要只看
USER_TAB_STATISTICS.STALE_STATS：它只反映“是否过期”，不反映“是否可用” - 真正影响估算的是
GLOBAL_STATS和NUM_ROWS是否可信，而这两者在复合表中极易脱节 - 即使你刚对新增子分区 gather 了一次，旧子分区若未更新，
GLOBAL_STATS仍被标记为不可信
修复 Stale + GLOBAL_STATS=NO 的最快路径
别用 GRANULARITY => 'ALL' 全量重刷——对百级子分区表，耗时可能超 2 小时，且期间阻塞 DML。更务实的做法是分两步补全可信的全局统计：
- 先快速估算全局行数：
SELECT SUM(num_rows) FROM dba_tab_subpartitions WHERE table_name = 'YOUR_TABLE' - 再用
DBMS_STATS.SET_TABLE_STATS手动注入：DBMS_STATS.SET_TABLE_STATS(ownname=>'SCHEMA', tabname=>'YOUR_TABLE', numrows=>12345678, stattype=>'DATA') - 最后强制标记为有效：
DBMS_STATS.LOCK_TABLE_STATS不起作用，但DBMS_STATS.UNLOCK_TABLE_STATS+ 再SET可绕过部分校验
注意：SET_TABLE_STATS 不会更新列级直方图或索引统计，仅解决跨分区行数误判这个最痛的点。
为什么 DEGREE 并行对复合表统计收集收效甚微
设 DEGREE => 8 + GRANULARITY => 'PARTITION'，看似并发，实则多数时间卡在字典锁争用上。因为所有 worker 进程都要反复访问 sys.tabsubpart$ 和 sys.col$ 更新元数据，而这些基表没有按子分区做细粒度锁拆分。
实测表明：对含 64 个子分区的 RANGE-LIST 表，GRANULARITY => 'GLOBAL' + DEGREE => 8 比 'PARTITION' 快 3.2 倍——它只扫一次数据字典，然后并行采样数据块，避免重复元数据解析。
- 别迷信“粒度越细越快”：复合表的统计瓶颈不在数据扫描，而在元数据协调
- 如果必须局部更新（比如只增了 2 个子分区），改用
GRANULARITY => 'SUBPARTITION'显式指定范围，比'PARTITION'更精准 -
NO_INVALIDATE => FALSE对GLOBAL_STATS标记无效，这个参数只控制游标是否失效，不干预统计有效性判定
真正容易被忽略的是：复合分区表的统计“可信性”不取决于你收集了多少，而取决于 Oracle 是否认为它已完整覆盖所有子分区。哪怕只漏掉一个子分区的统计，GLOBAL_STATS 就永远是 'NO'，优化器就永远不敢信你的 NUM_ROWS。
