关系型数据库性能调优方法论：从 SQL 到系统瓶颈

数据库慢了，很多人的第一反应是加索引、加缓存、加机器。它们可能有效，但也可能只是把问题推迟。成熟的性能调优应该建立完整证据链：慢在哪里，为什么慢，改动会影响哪个指标，是否引入新风险。

关系型数据库性能问题通常横跨 SQL、索引、事务、锁、连接池、磁盘 IO、内存、复制和应用访问模式。

先看端到端

用户感受到的是接口延迟，不是数据库单点指标。先确认：

• 是所有接口慢，还是某几个接口慢。
• 是平均慢，还是 p99 慢。
• 是持续慢，还是高峰慢。
• 是数据库执行慢，还是连接等待慢。
• 最近是否有发布、数据增长或流量变化。

不要只看平均值。数据库问题常表现为 p95/p99 抖动。

慢 SQL

开启慢查询日志或使用 pg_stat_statements、performance_schema 等工具，找出高耗时、高频率、高扫描量 SQL。

慢 SQL 分析重点：

• 扫描行数。
• 返回行数。
• 是否使用索引。
• 是否排序或临时表。
• 是否 JOIN 顺序异常。
• 是否锁等待。

一条执行 5 秒但每天一次的 SQL，优先级可能低于每天执行百万次、每次 50ms 的 SQL。

锁等待

锁等待会让数据库 CPU 看起来不高，但接口大量超时。常见原因：

• 大事务。
• 批量更新。
• 缺索引导致锁范围过大。
• 热点行频繁更新。
• DDL 与 DML 冲突。

优化方式：

• 缩短事务。
• 小批量提交。
• 热点数据拆分。
• 增加更新条件索引。
• 把外部调用移出事务。

连接池

连接池配置不当也会导致慢。连接太少，应用排队；连接太多，数据库上下文切换和内存压力上升。

建议按数据库实例能力、应用副本数和请求模型计算总连接数。不要每个微服务副本都开几百连接，最终把数据库连接打满。

连接池要设置合理超时，避免请求无限等待。

缓存不是万能药

缓存适合高频读取、可接受短暂不一致的数据。它不能解决所有慢查询。错误缓存会带来脏数据、击穿、雪崩和一致性问题。

优先优化源头 SQL 和索引，再用缓存削峰。对核心强一致数据，缓存只能作为辅助，不应成为唯一判断来源。

IO 与内存

数据库性能高度依赖内存命中率和磁盘延迟。MySQL 关注 buffer pool 命中、redo log、flush、临时表；PostgreSQL 关注 shared buffers、WAL、checkpoint、VACUUM、临时文件。

如果工作集远大于内存，数据库会频繁读盘。此时加索引或调参数效果有限，需要归档、分区、扩容内存或拆分热冷数据。

参数调优

参数调优必须基于指标。不要复制网上模板。不同数据量、硬件、并发和业务模型，参数差异很大。

常见参数方向：

• 缓冲池或共享缓冲。
• 日志刷盘策略。
• checkpoint。
• 临时内存。
• 连接数。
• autovacuum。

任何参数变更都要记录、灰度、观察和回滚。

容量模型

最终要建立容量模型：

• 每秒读写请求数。
• 数据增长速度。
• 索引放大比例。
• 热数据大小。
• 连接数峰值。
• 事务耗时。
• 备份和复制延迟。

有容量模型，扩容才是计划；没有容量模型，扩容只是紧急操作。

总结

关系型数据库性能优化是一套系统工程。慢 SQL、索引、锁、连接池、IO、缓存和容量都要一起看。最好的调优不是临时救火，而是让团队持续知道瓶颈在哪里、增长趋势如何、下一次风险什么时候到来。