19c优化器因统计信息失效或执行路径退化导致物理I/O激增，表现为AWR中Physical Reads/Writes突增、db file scattered/sequential read等待飙升；需通过Top Segments和SQL ordered by Physical Reads定位问题SQL，结合DBMS_XPLAN.DISPLAY_AWR确认执行计划退化，并检查统计信息是否陈旧或直方图缺失。
不是存储或硬件变慢，而是19c优化器因统计信息失效或执行路径退化，把原本走缓存的逻辑硬拖进物理I/O——AWR里Physical Reads/Writes突增、db file scattered/sequential read等待飙升，基本就是这个信号。
查AWR中Physical Reads是否真由执行计划退化引发
别只盯着“Top SQL by Elapsed Time”。重点看两个地方：
- Top Segments by Physical Reads：找
OBJECT_TYPE = TABLE且PHYSICAL_READS远高于其他段的行；若同表在Top Segments by Direct Physical Reads也靠前，大概率是全表扫描在刷盘 - SQL ordered by Physical Reads：筛选
Physical Reads Per Exec > 10000且Executions > 5的语句；点开它的PLAN_HASH_VALUE，用DBMS_XPLAN.DISPLAY_AWR查执行计划，确认是否从11g的INDEX RANGE SCAN退化成19c的TABLE ACCESS FULL - 排除干扰：如果该SQL同时出现在
SQL ordered by Temp Space里，说明I/O可能来自临时段（哈希溢出、排序落盘），而非原表扫描
确认统计信息是否陈旧或直方图缺失
19c优化器对统计信息更敏感，旧统计会直接导致选择性误判：
- 查核心表最后分析时间：
SELECT owner, table_name, last_analyzed FROM dba_tables WHERE owner IN ('PROD') AND last_analyzed - 查关键字段是否有直方图：
SELECT column_name, histogram FROM dba_tab_col_statistics WHERE table_name = 'ORDER_HEADER' AND histogram = 'NONE'——状态码、类型码这类低基数高倾斜字段必须有SIZE 254直方图 - 对比执行计划差异：在19c中
EXPLAIN PLAN FOR慢SQL，再SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY)，重点看Rows预估是否严重偏离实际（如估100行、返50万行）
检查是否触发了19c特有的I/O恶化机制
有些I/O激增不是SQL写得差，而是19c新行为放大了旧隐患：
-
_pga_aggregate_target默认值未随内存同比例增长 → 小负载就触发sorts (disk)，查V$PGASTAT中cache hit percentage是否低于90% - 分区裁剪失效：执行计划出现
PARTITION RANGE ALL而非SINGLE或ITERATOR→ 检查WHERE是否用了分区键，且值是否可静态评估（避免SYSDATE、未传绑定变量） - 隐式转换强制全扫：
WHERE to_char(create_time) = '2026-08'→ 改为create_time >= DATE '2026-08-01' AND create_time - RAC节点间计划不一致：AWR聚合后I/O总量异常但找不到根因SQL → 必须加
instance_number过滤查DBA_HIST_SEG_STAT，否则看到的是多节点叠加值
最易被忽略的是：迁移后残留的11g动态采样Hint、未清理的_optimizer_ignore_hints隐含参数旧值，或者JDBC驱动版本太老（如ojdbc6）导致绑定变量窥探失效——这些不会报错，但会让统计信息和执行计划持续处于“半生效”状态。
