AWR中read by other session高说明多会话争抢同一逻辑块缓存加载权，非I/O慢而是访问路径重复；需查v$session_wait中file#/block#是否集中（如90%落在file#=5,block#=123456）以区分真热点或SQL分布问题。
AWR里read by other session高，说明多个会话在争抢同一组数据块的缓存加载权，不是I/O慢，而是访问路径高度重复。
怎么确认是真热点还是SQL分布问题
只看read by other session的总次数没用，必须查它是否集中在少数file#/block#上：
- 执行
SELECT p1 "file#", p2 "block#", p3 "class#" FROM v$session_wait WHERE event = 'read by other session'，观察结果是否90%以上落在同一组值（比如file#=5,block#=123456） - 如果分散：大概率是大量不同SQL做全表扫描或索引快速扫描，触发预读冲突，问题在SQL整体分布
- 如果集中：基本锁定为单个对象的热块，比如主键索引根块、小表唯一数据块、高频更新的配置表
定位热块对应的真实对象
DBA_OBJECTS.object_id ≠ X$BH.obj，直接关联会查错对象：
- 正确方式一（推荐）：
SELECT owner, segment_name, segment_type FROM dba_extents WHERE file_id = &FILE_ID AND &BLOCK_ID BETWEEN block_id AND block_id + blocks - 1 - 正确方式二（更准）：
SELECT o.owner, o.object_name, o.object_type FROM x$bh b, dba_objects o WHERE b.obj = o.data_object_id AND b.file# = &FILE_ID AND b.dbablk = &BLOCK_ID - 如果两种都查不到：该块可能属于undo段、临时段，或已DROP但未清理的对象，需进一步查
v$database_block_corruption或v$tempseg_usage
区分是scattered read还是sequential read引发的争用
read by other session几乎总是和db file scattered read或db file sequential read同时出现，但优化方向完全不同：
- 若伴随大量
db file scattered read：说明是全表扫描或索引快速扫描（fast full scan），多个会话并发扫同一张大表 → 检查统计信息是否陈旧、谓词是否缺失、是否应改用索引访问路径 - 若伴随大量
db file sequential read：更可能是索引唯一扫描卡在热点索引块（如主键/唯一索引根块），或回表时反复访问同一数据块 → 优先检查索引选择性、列数据分布、是否需要加复合索引或调整PCTFREE
真正难处理的是那种“SQL执行计划没问题、统计信息也准、但就是几十个会话反复打同一块”的情况——这时候得看应用层有没有疯狂重试逻辑，或者前端是不是点了提交按钮后用户不停刷新页面。这类问题不从源头限流，光调SQL和索引效果有限。
