SQL Ordered by Gets 直接反映CPU和内存访问压力，统计SQL从buffer cache读取数据块的次数（Buffer Gets），每次涉及定位、pin、一致性检查及CR构造等CPU密集操作；高Gets易引发CPU满载、latch争用及library cache命中率下降，比高物理读更早暴露性能危机。
SQL Ordered by Gets 直接反映CPU和内存访问压力
它统计的是 sql 执行过程中从 buffer cache 中读取数据块的次数（buffer gets），不是物理读，也不是逻辑读总量——而是“访问内存中数据块”的动作频次。一次 buffer get 意味着一次对 sga 中 buffer 的定位、pin、检查一致性、可能还要做 cr（consistent read）构造。这些操作全在 cpu 上完成，且依赖 buffer cache 的组织结构（hash chain、latch 争用等）。所以高 gets 不代表磁盘慢，而代表 cpu 在反复折腾内存里的块。
为什么高 Gets 往往比高 Physical Reads 更危险？
常见错误是盯着 SQL ordered by Physical Reads 找“慢 SQL”，但一个 SQL 每次执行只读 10 块磁盘，却执行 10 万次、每次做 20 万次 Buffer Gets，它照样能把 CPU 打满、把 shared pool latch 锁死。你看到的现象可能是：DB time 高、latch free 或 cache buffers chains 等待飙升、library hit% 下跌——这些都比磁盘 IO 更早、更剧烈地暴露问题。
-
Buffer Gets per Exec> 100,000 且Rows Processed per Exec - 同一
SQL Id的Executions高但Elapsed Time per Exec波动大：说明受 latch/lock 争用影响，不是 SQL 本身逻辑问题 -
SQL ordered by Gets排名靠前的语句，SQL ordered by Elapsed Time却不靠前：典型 CPU-bound + 内存结构争用场景
Gets 高但响应快？小心“假象”
有些 SQL Buffer Gets 极高但单次 Elapsed Time 很短，容易被忽略。但它可能正在持续消耗 CPU 时间片、推高 DB CPU 和 DB time，同时挤占其他会话资源。尤其当 Instance Efficiency Percentages 中的 Buffer Nowait% 开始下降（比如低于 99%），就说明 buffer 访问已出现排队——这是内存压力从“隐性”转向“显性”的临界点。
真正难诊断的，从来不是磁盘读不动，而是内存里“抢不到位置”。AWR 报告里每一条高 Gets 的 SQL，背后都可能是 latch、shared pool、甚至 cursor sharing 的连锁反应。别只看数字大小，要看它在哪一节冒头、和哪些等待事件共现、是否伴随游标重解析或 buffer chain 加长。
