1. 交易数据库性能优化导论

交易数据库(OLTP)与报表分析、批处理系统在性能诉求上有本质差异。理解这些差异,是后续所有优化手段的出发点。本章先建立三个基础认知:核心交易场景到底有什么特征、用什么指标衡量性能、以及瓶颈通常出现在哪里。

一、核心交易场景的四个特征

典型的交易场景包括订单创建、支付扣款、库存扣减、账户转账、话单入库等。它们共同具备以下特征:

  • 高并发、短事务:单笔事务通常在毫秒级完成,但每秒可能有数千甚至上万笔并发提交。事务越短,锁持有时间越短,并发吞吐越高。
  • 读写混合且以索引点查为主:绝大多数 SQL 是通过主键或唯一索引定位少量行,全表扫描在交易路径上通常是异常信号。
  • 强一致性与提交敏感性:用户点击"支付"后必须立即得到确定结果,因此 COMMIT 的日志写入(LGWR 写 redo)往往成为关键路径。
  • 负载具有明显的峰谷:大促、整点、月初出账等时段并发陡增,系统必须按峰值而非均值设计容量。

这四点决定了交易库优化的核心矛盾:在保证数据不丢、事务不串的前提下,尽可能缩短单次事务的响应时间并提升并发吞吐。任何以牺牲一致性换取速度的做法,在交易场景中都不成立。

二、性能指标体系:从用户感知到数据库内部

性能不能只看一个数字。业界常用"响应时间—吞吐量—资源利用率"三角来描述,但落到 Oracle 交易库,需要更细的分层指标:

层级关键指标典型参考值(示例)
用户感知层平均响应时间、P99 响应时间、超时率P99 < 200ms
数据库吞吐层每秒事务数(TPS)、每秒执行次数、逻辑读/秒TPS 5000+
SQL 执行层单次执行耗时、执行次数、Buffer Gets/Exec、Disk Reads/Exec点查 Buffer Gets < 10
等待事件层DB Time、Top Wait Event、平均等待时间DB CPU 占比 > 60%
资源层CPU 使用率、I/O 延迟、redo 写速率、PGA/SGA 命中率单次 I/O < 1ms(SSD)

其中 DB Time 是最重要的宏观指标,它等于所有前台会话消耗的 CPU 时间加上等待时间。若 DB Time 远大于经过时间(Elapsed Time)乘以 CPU 核数,说明系统已出现明显排队。判断性能问题,第一步永远是看 AWR 报告中的 DB Time 与 Top 10 等待事件,而不是凭直觉猜测。

响应时间与吞吐量并非总是正相关:当并发超过系统最优并发点后,吞吐量会下降而响应时间急剧上升,这就是"排队崩溃"现象。优化目标应是找到并维持最优并发区间。

三、优化目标:不是越快越好,而是"稳定达标"

交易库优化的目标可以概括为三条:

  1. 满足 SLA:在峰值负载下,P99 响应时间仍满足业务约定,而非平均值达标。
  2. 留有余量:CPU、I/O、连接数等关键资源在峰值时不超过 70%~80%,为突发流量留缓冲。
  3. 可预测、可回退:任何优化变更都应能通过 AWR 前后对比量化效果,并具备回退方案。

需要强调的是,优化不是无限制地追求低延迟。把 P99 从 200ms 压到 50ms 可能带来数倍成本,而业务并不需要。因此优化的第一步是明确目标值,再倒推需要解决哪些瓶颈。

四、常见瓶颈分类

交易库瓶颈大致可分为五类,它们往往相互关联:

  • SQL 与执行计划类:缺失索引、索引选择错误、绑定变量窥探导致计划翻转、全表扫描。
  • 并发与锁类:行锁竞争、enq: TX - row lock contention、序列(sequence)争用、latch/mutex 争用。
  • I/O 类:db file sequential read 延迟高、redo 日志写慢、临时表空间争用。
  • 内存与配置类:SGA/PGA 不足导致物理读偏高、共享池硬解析频繁。
  • 应用与架构类:长事务、连接池配置不当、批量操作混入交易路径、缺少读写分离。

下图给出从"用户感知变慢"到"定位瓶颈类别"的判断路径,帮助在实际排障中快速收敛方向。

交易库性能瓶颈定位路径 用户感知:响应变慢 / 超时 查 AWR:DB Time 是否远大于 Elapsed×CPU核数? 看 Top 10 等待事件:CPU 还是等待占主导? CPU 主导 SQL 执行次数多 / 逻辑读高 等待主导 锁 / I/O / latch 排队 配置/架构主导 内存不足 / 连接池 / 长事务 五类瓶颈:SQL与执行计划 · 并发与锁 · I/O · 内存与配置 · 应用与架构 定位后需用 AWR 前后对比量化效果,并保留回退方案 目标:峰值下 P99 达标,关键资源利用率 ≤ 70%~80%

五、一个可复用的判断示例

假设某订单库在整点出现响应变慢。按上述路径:先取该时段 AWR,发现 DB Time 为 3600 秒,Elapsed 为 600 秒,CPU 核数 8,则 600×8=4800 秒,DB Time 未超过,说明系统尚未严重排队;再看 Top 等待事件,若 db file sequential read 平均等待 8ms(SSD 正常应 <1ms),则瓶颈指向 I/O;进一步查 SQL 统计,若某条按订单号查询的 SQL 执行计划由索引唯一扫描变为全表扫描,则根因是执行计划翻转。此时优化动作是稳定执行计划(如使用 SQL Plan Baseline),而非盲目加索引。

这个例子说明:性能优化是"测量—定位—验证"的闭环,而不是经验主义的试错。后续章节将围绕这条主线,逐一展开 SQL 优化、索引设计、等待事件分析、内存与 I/O 调优、锁与并发控制等具体方法。

本章要点回顾:交易场景 = 高并发 + 短事务 + 强一致 + 峰谷明显;核心指标 = DB Time、TPS、P99、Top Wait Event;优化目标 = 峰值达标 + 留余量 + 可回退;瓶颈五分类 = SQL/锁/I/O/内存/架构。