查分区行数和空间应联查user_tab_partitions与user_segments视图，num_rows为采样估算值，bytes为已分配空间而非实际使用量，需注意大小写匹配和表名大写。
直接查 DBA_TAB_PARTITIONS 和 DBA_SEGMENTS 联合结果，就能拿到每个分区的估算行数、分配空间和最后统计时间；但别指望它实时准确——NUM_ROWS 依赖统计信息是否刷新，BYTES 是段级分配量，不是真实使用量。
查分区空间占用：用 USER_TAB_PARTITIONS + USER_SEGMENTS 联查
这是最常用、开销最低的方式，适合日常巡检。关键点在于两视图字段对齐和大小写敏感：
-
USER_TAB_PARTITIONS.PARTITION_NAME默认大写，USER_SEGMENTS.PARTITION_NAME必须完全一致才能 JOIN - 必须显式指定
WHERE table_name = 'YOUR_TABLE_NAME'，且表名也需大写 -
NUM_ROWS是采样估算值，若未执行过DBMS_STATS.GATHER_TABLE_STATS，可能为NULL或偏差极大 -
BYTES来自USER_SEGMENTS，反映已分配空间（含空块、未格式化块），不是实际数据占用
示例语句：
SELECT p.partition_name,
s.bytes / 1024 / 1024 AS mb,
p.num_rows,
p.last_analyzed
FROM user_tab_partitions p
JOIN user_segments s
ON p.partition_name = s.partition_name
AND s.segment_name = p.table_name
WHERE p.table_name = 'SALES_DATA'
ORDER BY p.partition_name;
查真实行数但不锁表：用 SAMPLE BLOCK 按分区采样
全表 COUNT(*) 在大分区表上会严重阻塞 DML，而 SAMPLE BLOCK 可在毫秒级返回近似结果，误差通常
- 必须显式指定分区名，如
PARTITION (P_2024_Q3)；不能在主表名后直接加SAMPLE，否则仍是全表扫描 -
SAMPLE BLOCK (1)表示随机采样约 1% 的数据块；精度不够时可升到SAMPLE BLOCK (5)，但耗时线性增长 - 该方式不依赖统计信息，也不触发 DML 锁，适合生产环境紧急排查
示例语句：
SELECT COUNT(*) AS row_count FROM sales_data PARTITION (P_2024_Q3) SAMPLE BLOCK (1);
RAC 环境下分区空间监控必须逐节点执行
DBA_FREE_SPACE 是实例级缓存视图，在 RAC 中每个节点只维护本地 LRU 刷新的空闲块信息，跨节点查询会漏数据、误判使用率：
- 不能只连一个节点查完就认为“全集群已满”，必须用
sqlplus / as sysdba分别登录每个节点执行空间查询 - 高并发 DML 后，
DBA_FREE_SPACE可能有数秒延迟；紧急判断前建议先执行ALTER SYSTEM CHECKPOINT - 如果某节点报
ORA-01219: database not open，说明该实例未正常启动，需检查crsctl stat res -t
识别分区数据倾斜：别只看单个数字，要算相对偏差
分区表的价值在于均衡分布，但业务写入往往导致严重倾斜。光看 NUM_ROWS 或 MB 没意义，得看离散程度：
- 用标准差或变异系数（标准差 / 均值）量化分布离散度，比最大/最小值比更稳定
- 结合
LAST_ANALYZED时间判断统计是否过期：若某分区last_analyzed是半年前，而其他都是昨天，大概率该分区近期有大量写入但未重收集统计 - 真正的问题常藏在“看起来正常”的分区里——比如某个分区
NUM_ROWS为 0 但BYTES > 0，说明有空段残留或高水位未下降
复杂点在于：NUM_ROWS 不可靠、BYTES 不精确、RAC 下数据视图不一致——这些不是配置问题，是 Oracle 底层设计决定的，绕不开，只能分场景选方法。
