read by other session 等待事件本质是多会话争抢同一逻辑块的缓存加载权，核心在访问路径重复而非i/o慢；须通过v$session_wait查file#/block#定位热点，结合dba_extents或x$bh精准识别争用对象，并依db file scattered/sequential read类型差异分别优化sql执行计划、索引设计或应用层限流。
read by other session 等待不是i/o慢，而是多个会话抢着读同一块缓存数据——优化核心是切断“重复读同一块”的路径，而不是加内存或换磁盘。
查清谁在争哪一块：用 v$session_wait 定位热点 file#/block#
这个等待事件的三个参数 file#、block#、class# 是唯一可信线索。只看等待次数没用，必须确认是否反复落在同一组 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 分布；若高度集中，基本锁定为单个对象的热块（如索引根块、小表的唯一数据块）
- 注意：
block#是逻辑块号，不是物理偏移，直接用它查DBA_EXTENTS才能定位到真实段
定位热块对应对象：别依赖 DBA_OBJECTS 直接关联
X$BH 中的 OBJ 字段对应的是 DATA_OBJECT_ID，不是 OBJECT_ID，用错会导致查到错误对象：
- 正确写法：
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 - 更准的方式是结合
X$BH和DBA_OBJECTS：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 - 如果返回为空，说明该 block 属于系统段（如 undo、temp）或已 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：更可能是索引唯一扫描（index unique scan）或回表访问时卡在某个热点索引块（如主键索引根块、唯一约束所在块）→ 检查该索引是否高度倾斜（如 status='ACTIVE' 占 99%）、是否可拆分（reverse key index）或加 hint 强制走其他索引 - 一个典型陷阱：
INDEX RANGE SCAN返回 1 行，但扫描了上万行索引条目，仍会触发大量read by other session—— 这时候看执行计划比看等待更管用
避免盲目增大 db_cache_size 或启用 db_flash_cache_file
这块最容易踩坑：热块问题本质是逻辑访问模式冲突，不是缓存不够：
- 增大 buffer cache 对单块热争用（如索引根块）几乎无效，因为那个块本来就在 cache 里，只是被反复请求加载副本
-
db_flash_cache_file在 12c 中仅加速物理读，不缓解 “第一个会话正在读、其他会话干等” 这一同步等待 - 真正有效的干预点只有三个：
SQL 执行计划修正（加 hint / 收集统计信息 / 改写）、对象设计调整（分区、反向索引、压缩）、应用层限流（如对高频查询加缓存或合并请求） - 临时缓解可用
ALTER SYSTEM FLUSH BUFFER_CACHE，但仅用于验证是否真为热块 —— 刷完立刻复现，就坐实了是访问模式问题
最常被忽略的一点：read by other session 的等待时间单位是微秒（microseconds），AWR 报告里显示为 0ms 很正常，不能因此认为“不严重”。要看的是它在 Top Event 中的占比和绝对等待次数 —— 一次等待 100μs 不打紧，但每秒发生 5000 次，就是 500ms 的有效延迟累积。
