应优先分析“segments by physical reads”定位真实io压力源，因物理读高直接反映磁盘i/o瓶颈；逻辑读高仅说明缓存访问频繁，未必存在性能问题。
看“Segments by Logical Reads”找缓存层热点
逻辑读高不等于慢，但说明这块数据被反复从Buffer Cache里翻出来——可能是高频访问的热表，也可能是执行计划差导致反复扫同一张小表。重点关注Object Name列中类型为TABLE或INDEX的行，尤其是%Total超过5%的对象。
常见误判点：
- 把分区表的子对象（如
SALES_2024_Q1）当成独立热点，其实它只是主表SALES的一个切片，优化应聚焦在主表索引和统计信息上 -
Logical Reads高但Physical Reads极低，大概率是SQL写法问题（比如嵌套循环驱动了大表），不是IO瓶颈 - 系统表（如
OBJ$、IND$）偶尔冲高，通常是DDL密集期或字典缓存刷新，不用急着干预
盯紧“Segments by Physical Reads”确认真实IO压力源
这才是索引缺失或结构失衡的直接证据。物理读高=数据库被迫从磁盘一块块搬数据，典型场景就是全表扫描或索引快速全扫（INDEX FAST FULL SCAN）。优先筛选Object Type为INDEX且Physical Reads突增的条目。
实操要点：
- 对比最近7天同一时段的
Physical Reads均值，单日翻倍以上才值得深挖 - 若某
INDEX的Physical Reads远高于同表其他索引，先查它是否被DBA_HIST_SQL_PLAN中的FULL TABLE SCAN反向引用——说明优化器弃用了它 - RAC环境务必核对
Instance ID列，避免把节点B的局部热点当成全局问题
用DBA_HIST_SEG_STAT交叉验证访问模式
AWR报告里的段统计是聚合快照，细节藏在基表里。直接查DBA_HIST_SEG_STAT能看清是读多还是写多、是随机读还是顺序读：
SELECT owner, object_name, object_type,
SUM(physical_reads) phys_reads,
SUM(logical_reads) log_reads,
SUM(db_block_changes) block_changes
FROM dba_hist_seg_stat s
JOIN dba_hist_snapshot sn ON s.snap_id = sn.snap_id
WHERE sn.begin_interval_time > SYSDATE - 1
AND object_type IN ('TABLE', 'INDEX')
GROUP BY owner, object_name, object_type
ORDER BY phys_reads DESC;
关键判断依据：
- 同一张表
phys_reads高 +block_changes也高 → 可能是高并发UPDATE导致索引分裂，需检查CLUSTERING_FACTOR -
log_reads极高但phys_reads低 → 热点在内存，但SQL可能没走索引（比如INDEX RANGE SCAN返回1000行却预估10行），该补统计信息 -
object_type = 'INDEX'且phys_reads占比超表本身 → 索引可能过大或选择性崩坏，考虑重建或删冗余索引
别漏掉“Segments by Physical Read Requests”里的异常信号
这个视图常被忽略，但它能暴露更底层的问题：Physical Read Requests数值小但Physical Reads极大，说明每次I/O都在读大块（比如全表扫描）；反过来，如果Requests很高而Reads不高，可能是大量小IO堆积（比如索引跳跃扫描+回表）。
特别注意：
- 当
Segments by Physical Reads和Segments by Physical Read Requests排序高度重合时，基本可排除瞬时毛刺，确认是结构性热点 - 某些LOB索引会归类为
LOBSEGMENT而非INDEX，需额外用DBA_SEGMENTS过滤segment_type LIKE '%LOB%'来补全 - 如果某索引在
Physical Reads榜上前五，但在Physical Read Requests里排名靠后，大概率是INDEX FAST FULL SCAN——这种扫描无法使用索引有序性，等价于扫表
实际定位时，最易被跳过的是“时间窗口一致性”：比如用业务高峰期的快照去比对夜间备份窗口的DBA_HIST_SEG_STAT，数据自然失真。所有查询必须严格限定在同一begin_interval_time范围内，否则看到的只是噪音。
