incremental = true 必须配 granularity = 'auto' 或 'all' 才生效，因 oracle 仅在此两种粒度下扫描变更分区、复用 synopsis 并合并全局统计；设为 'global' 会跳过分区收集导致 synopsis 链断裂。
INCREMENTAL = TRUE 为什么必须配 GRANULARITY = 'AUTO'
单独设 INCREMENTAL 为 'TRUE' 不生效。Oracle 只有在 GRANULARITY 是 'AUTO' 或 'ALL' 时，才会真正触发增量逻辑：扫描变更分区、读取已有 synopsis、合并生成全局统计。若设成 'GLOBAL'，DBMS_STATS 直接跳过所有分区级收集，导致 synopsis 链断裂，后续增量永远失效。
常见错误是误以为 GRANULARITY => 'GLOBAL' 能“快速更新全局”，结果反而让分区统计持续陈旧，优化器选错执行路径。
-
GRANULARITY = 'AUTO'：Oracle 自动判断，对范围/列表分区通常走增量；对哈希分区可能退化为全量（因数据均匀变更） -
GRANULARITY = 'ALL'：强制收集全局 + 所有分区，但只对变更分区做实际扫描，其余复用 synopsis - 查当前设置：
SELECT DBMS_STATS.GET_PREFS('GRANULARITY', 'SCHEMA_NAME', 'TABLE_NAME') FROM DUAL
第一次启用增量前必须手动初始化 ALL 粒度
已有陈旧统计的表，直接开 INCREMENTAL 不会自动补 synopsis。Oracle 会继续用老的全局统计，直到下一次全量收集——而你本意是避免全量。
必须显式执行一次 GATHER_TABLE_STATS 并指定 granularity => 'ALL'，才能把当前所有分区的统计写入 WRI$_OPTSTAT_SYNOPSIS$，建立初始摘要链。
- 命令示例：
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA_NAME', tabname => 'TABLE_NAME', granularity => 'ALL') - 这步耗时接近全量收集，但只需做一次；之后每次增量只处理变动分区
- 若跳过此步，后续
INCREMENTAL收集看似成功，LAST_ANALYZED更新了，但NUM_ROWS等全局值仍是旧的
哈希分区慎用 INCREMENTAL
哈希分区天然数据分布均匀，新插入数据大概率分散到所有分区。这时 INCREMENTAL 不仅不省时间，反而因维护 synopsis 多出额外开销，实测常比 granularity => 'ALL' 全量还慢。
范围/列表分区才真正受益：每天只新增一个分区，或仅少数分区被批量更新，其余分区统计长期有效。
- 验证分区变更情况：
SELECT PARTITION_NAME, NUM_ROWS, LAST_ANALYZED FROM DBA_TAB_PARTITIONS WHERE TABLE_NAME = 'TABLE_NAME' - 若发现多个分区
LAST_ANALYZED时间相近且频繁变动，说明增量收益低 - 哈希表建议保持
INCREMENTAL = 'FALSE'，改用ESTIMATE_PERCENT => 10加快采样
SYSAXU 表空间会随增量使用持续增长
每个分区每列的 synopsis 存在 WRI$_OPTSTAT_SYNOPSIS$，长期运行后可能占满 SYSAXU。这不是 bug，是设计使然——Oracle 用空间换时间，但需要人工干预清理。
没人定期清理，SYSAXU 涨到 95%+ 会导致后续统计收集失败，报错 ORA-12801: error signaled in parallel query server 或直接卡住。
- 清理旧 synopsis：
EXEC DBMS_STATS.PURGE_STATS(SYSDATE - 30)（保留最近30天） - 查占用：
SELECT SUM(bytes)/1024/1024 FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = 'SYSAUX' AND SEGMENT_NAME LIKE 'WRI$_OPTSTAT%' - 清理后记得
ANALYZE TABLE WRI$_OPTSTAT_SYNOPSIS$ COMPUTE STATISTICS，否则后续收集变慢
真正决定增量是否有效的，不是开关本身，而是分区变更模式和首次初始化动作。很多性能问题其实源于没跑那一次 granularity => 'ALL'，或者在哈希表上硬套增量策略。
