DBA_TAB_PARTITIONS.NUM_ROWS经常不准，因其仅反映上一次指定granularity=>'PARTITION'或'ALL'的GATHER_TABLE_STATS执行后的快照值，DML后未重收集即过期，甚至为NULL。
为什么 DBA_TAB_PARTITIONS 里的 NUM_ROWS 经常不准
因为这个字段不实时更新，它只反映上一次执行 dbms_stats.gather_table_stats（且指定 granularity => 'partition' 或 'all'）后的快照值。如果分区有大量 dml 但没重新收集统计信息，num_rows 就是过期的——甚至可能是 null（表示从未收集过该分区统计）。
常见错误现象：SELECT COUNT(*) FROM tab PARTITION (p202401) 返回 120 万，但 DBA_TAB_PARTITIONS.NUM_ROWS 显示 89 万或 NULL。
- 使用场景：快速估算分区规模、判断是否需要重收集、排查查询计划偏差
- 参数差异：
granularity必须设为'PARTITION'或'ALL'，设成'GLOBAL'不会填充各分区的NUM_ROWS - 性能影响：对大表单分区执行
COUNT(*)可能扫描全分区，而统计信息读取是毫秒级
如何安全、准确地获取每个分区的当前行数
最可靠的方式是结合统计信息（快）和按需采样（准），而不是盲目扫全表。优先走 DBA_TAB_PARTITIONS + 刷新策略，必要时再补查。
- 先检查统计是否可用：
SELECT PARTITION_NAME, NUM_ROWS, LAST_ANALYZED FROM DBA_TAB_PARTITIONS WHERE TABLE_NAME = 'YOUR_TABLE' AND TABLE_OWNER = 'OWNER' - 若
NUM_ROWS IS NULL或LAST_ANALYZED超过 1 天，说明统计陈旧，应触发收集：EXEC DBMS_STATS.GATHER_TABLE_STATS('OWNER', 'YOUR_TABLE', granularity => 'PARTITION', degree => 4) - 若需即时精确值且分区不大（比如 SELECT COUNT(*) FROM OWNER.YOUR_TABLE PARTITION (P202401)
- 若分区极大，用采样估算：
SELECT /*+ SAMPLE(1) */ COUNT(*) * 100 FROM OWNER.YOUR_TABLE PARTITION (P202401)（注意：采样率需根据实际数据分布调整）
DBA_TAB_PARTITIONS.NUM_ROWS 和实际行数差几倍？什么情况下会严重失真
失真不是随机的，往往集中在三类分区：刚交换进来的新分区（EXCHANGE PARTITION 后未收集）、频繁 INSERT/DELETE 但无定期统计任务的热分区、以及启用 INMEMORY 但统计未覆盖内存格式的分区。
- 典型错误现象：
NUM_ROWS = 0但分区里明明有数据（常见于EXCHANGE后忘记GATHER） - 兼容性影响：Oracle 12c 及以后支持
INCREMENTAL统计，开启后可大幅降低全表重收集开销，但需确保DBMS_STATS.SET_TABLE_PREFS中'INCREMENTAL'设为'TRUE' - 容易被忽略的点：
NUM_ROWS是优化器估算基数的依据，失真会导致执行计划选错索引或走错连接方式，比“看数不准”后果更严重
脚本化批量检查与修复分区行数统计
别手动一条条查，写个简单 PL/SQL 块自动识别并处理异常分区。核心逻辑是：找出 NUM_ROWS IS NULL 或 LAST_ANALYZED < SYSDATE - 1 的分区，然后调用 GATHER。
BEGIN
FOR r IN (
SELECT TABLE_OWNER, TABLE_NAME, PARTITION_NAME
FROM DBA_TAB_PARTITIONS
WHERE TABLE_NAME = 'YOUR_TABLE'
AND (NUM_ROWS IS NULL OR LAST_ANALYZED < SYSDATE - 1)
) LOOP
DBMS_STATS.GATHER_TABLE_STATS(
ownname => r.TABLE_OWNER,
tabname => r.TABLE_NAME,
partname => r.PARTITION_NAME,
granularity => 'PARTITION'
);
END LOOP;
END;
运行前确认用户有 ANALYZE ANY 或目标表的 ANALYZE 权限；生产环境建议加 degree => 2 控制并发，避免资源争抢。
分区多、数据量大的时候，LAST_ANALYZED 时间戳和真实数据变化之间总有延迟，指望它完全实时不现实——关键是建立匹配业务节奏的统计刷新机制，而不是每次都要“立刻知道准确数”。
