最准、最轻量的方式是直接查dba_extents，但必须同时查看file_id、block_id、blocks三列；单看segment_name易混淆分区与段类型，bytes是受db_block_size和四舍五入影响的换算值，无法准确判断物理连续性。
直接查 DBA_EXTENTS 就是最准、最轻量的方式，但必须连查 FILE_ID、BLOCK_ID、BLOCKS 三列，否则看到的只是“碎片化幻觉”。
为什么不能只看 SEGMENT_NAME 或 BYTES
单独过滤 SEGMENT_NAME 容易把不同分区、不同段类型（比如主表 + LOBSEGMENT）混在一起；而 BYTES 是换算值，受 DB_BLOCK_SIZE 和四舍五入影响——例如 BLOCKS = 7 时，BYTES 可能显示为 57344 或 65536，用它加减判断连续性必然出错。
真正反映物理分配的是三元组：FILE_ID（哪个文件）、BLOCK_ID（该文件内起始物理块号）、BLOCKS（占多少块）。这三个字段在 DBA_EXTENTS 中永远真实、无损、可比对。
-
BLOCK_ID是物理块号，不是逻辑序号，也不是操作系统偏移 - 值小于 10 的
BLOCK_ID通常是文件头或位图块，不能参与连续性计算 - 临时段、回滚段、UNDO 段不进
DBA_EXTENTS，查它们得走V$TEMPSEG_USAGE、DBA_ROLLBACK_SEGS或DBA_UNDO_EXTENTS
查单个表/索引的区分布：必须带 OWNER + SEGMENT_NAME + SEGMENT_TYPE
分区表尤其容易踩坑：每个分区是独立段，SEGMENT_NAME 存的是分区名（如 TBL_P1），不是基表名。直接写 WHERE segment_name = 'MY_TABLE' 会查不到任何结果。
正确做法分两步：
- 先确认对象类型和归属：
SELECT partition_name, segment_type FROM dba_segments WHERE owner = 'SCHEMA_NAME' AND segment_name = 'MY_TABLE'; - 再查具体区信息：
SELECT file_id, block_id, blocks, extent_id FROM dba_extents WHERE owner = 'SCHEMA_NAME' AND segment_name = 'MY_TABLE' AND segment_type = 'TABLE';
如果对象是分区表且你关心某个分区，把 segment_name 换成对应分区名，并确保 segment_type 是 'TABLE PARTITION'。
判断是否跨数据文件：只看 FILE_ID 是否唯一
一个段跨文件，意味着它的 extents 分散在多个 FILE_ID 上——这会影响 I/O 局部性，但 Oracle 自动管理，除非 v$filestat 显示某文件 phyrds 明显偏高，否则无需干预。
执行这个聚合查询就能一眼看出：
SELECT owner, segment_name, file_id, COUNT(*) extent_count FROM dba_extents WHERE owner = 'SCHEMA_NAME' AND segment_name = 'MY_TABLE' GROUP BY owner, segment_name, file_id ORDER BY file_id;
返回多行？说明跨文件。返回一行？全部 extents 都落在同一个 FILE_ID 上。
- 别用
TABLESPACE_NAME分组——同一表空间可含多个文件，但段可能只占其中一部分 - 别漏
OWNER条件，否则会把同名不同 schema 的对象混进来 - Bigfile 表空间下
BLOCK_ID仍是 32 位范围（0～4G−1），不反映文件总大小，但不影响跨文件判断
验证两个 extent 是否物理相邻：只认这个等式
物理连续 ≠ 逻辑顺序，也不等于 BYTES 看起来挨着。真正相邻的充要条件只有：
t1.FILE_ID = t2.FILE_ID AND t1.BLOCK_ID + t1.BLOCKS = t2.BLOCK_ID
实操中三个点最容易漏：
- 没排除
BLOCK_ID 的记录（文件头/位图块） - 没限定同一
OWNER和SEGMENT_NAME，把不同对象的 extent 错误拼接 - 用
BYTES替代BLOCKS做加减——这是最隐蔽也最常犯的错
如果你真在调优 I/O 局部性或准备 ALTER TABLE ... MOVE，连续性判断必须严格按这个三元组来，其他都是干扰项。
