3. 性能优化方法论与容量规划流程

很多团队做 Oracle 性能优化时，习惯从“数据库现在哪里慢”出发：抓 AWR、看 TOP SQL、加索引、调参数。这套做法能解决局部问题，却常常陷入“救火—复发—再救火”的循环。根本原因在于：优化缺少业务锚点，容量规划缺少量化模型。本节要建立的，是一条从业务需求出发、经过负载量化、资源建模、优化验证，最终回到业务指标的闭环。

一、闭环的四个环节与它们之间的约束

这条闭环可以拆成四个环节：业务需求 → 负载模型 → 资源模型 → 优化与验证，验证结果再反馈修正负载模型和资源模型。它不是线性流程，而是一个带反馈的环。

关键约束有三条。第一，业务需求必须可量化，例如“日订单 80 万笔、峰值 1200 TPS、支付查询 P95 小于 200ms”，而不是“系统要快”。第二，负载模型必须能换算成数据库可观测的指标，例如每秒逻辑读、每秒物理读、每秒 redo 字节数、活跃会话数。第三，资源模型必须能回答“在给定硬件下，这套负载能否满足 SLA”，否则优化就没有验收标准。

二、从业务需求到负载模型：把“TPS”翻译成数据库指标

业务侧给出的通常是 TPS、订单量、用户数，而数据库关心的是逻辑读、物理读、redo 和会话数。中间需要一个换算过程。以订单库为例，假设业务需求为：日订单 80 万笔，峰值时段集中在 2 小时内，峰值 TPS 约 1200。每笔订单写入涉及 1 次订单主表 insert、3 次明细 insert、2 次状态更新，共约 6 次 DML。

再假设通过采样得知：单次订单写入平均产生 45 个逻辑读、8 个物理读、redo 约 2.4KB。那么峰值负载可估算为：

逻辑读/秒 = 1200 × 6 × 45 ≈ 324,000
物理读/秒 = 1200 × 6 × 8  ≈ 57,600
redo/秒   = 1200 × 6 × 2.4KB ≈ 17.3 MB/s
活跃会话  = 1200 × 平均响应时间(0.05s) ≈ 60

这些数字就是负载模型的输出，也是后续资源建模的输入。注意：这里的 45、8、2.4KB 属于教学示例假设，实际项目中必须通过 AWR 的 Load Profile 和 SQL Statistics 采样获得，不能拍脑袋。

三、从负载模型到资源模型：用“瓶颈定位”代替“盲目扩容”

有了负载，接下来判断资源是否够用。核心方法是把负载指标与硬件能力逐项比对，找出最先触顶的那一项。常见比对关系如下：

比对的目的是找到“短板”。如果 CPU 需要 4 核而物理读需要 384 盘等效能力，而现有存储只能提供 200 盘等效能力，那么瓶颈在 IO，而不是 CPU。此时加 CPU 无效，应先做 SQL 优化降低物理读，或调整存储。这就是资源模型的价值：它把“要不要扩容”变成“扩哪里、扩多少”。

四、优化与验证：用同一套指标做前后对比

优化动作必须可度量。建议在优化前后采集同一组指标：峰值时段逻辑读/秒、物理读/秒、redo/秒、平均响应时间、P95 响应时间、活跃会话数。以一条高频订单查询为例，优化前执行计划走全表扫描，逻辑读 12,000；增加组合索引后逻辑读降至 180，物理读从 900 降至 12。此时负载模型中的“单次查询逻辑读”假设应从 45 修正为更小的值，闭环回到负载模型。

五、可落地的闭环检查表

为了让闭环可执行，建议每次优化或容量规划都填写以下检查项。它既是工作模板，也是复盘依据。

总结来说，这条闭环的核心不是某个工具或某条命令，而是“业务可量化、负载可换算、资源可比对、优化可验证、模型可修正”这五个可。做到这五点，性能优化和容量规划才能从被动救火转为主动可控。