>十五年数据库相关经验，做过 DBA、架构师、技术顾问。不求"颠覆"，只求"靠谱"。


----

数据库装完就能跑，但默认配置离生产就绪差得远。

很多团队上线前做最后一件事：装数据库、导数据、应用连上去、测试跑通、上线。整套流程里没人去碰过数据库参数。

上个月接了一个线上性能问题，排查下来发现：8 核 32G 的服务器，`innodb_buffer_pool_size` 还是默认的 128M。数据库能跑通，但 90% 的读请求都要回磁盘。把 buffer pool 调到 20G，性能提升 3 倍。改了一个参数，没改任何代码。

干了这么多年 DBA，参数调优是最容易被忽视、也最容易出活的事情。今天把参数调优的方法论整理出来，从内存、连接、日志到优化器，一步一步说清楚。


----

## 01 内存参数——最花钱的硬件，别让它闲着


内存是数据库最重要的资源。磁盘慢、网络慢，但内存快。能把数据放进内存处理的，就不要让它去磁盘。

### MySQL：buffer pool 是头号参数


`innodb_buffer_pool_size` 控制 InnoDB 引擎缓存数据的内存大小。数据库读到数据页后，放进 buffer pool，下次再读同一条数据时，直接从内存返回，不用去磁盘。

**默认值**：128M。**生产建议**：内存总量的 60%-70%。

怎么算？假设服务器 32G 内存，操作系统和数据库进程本身大概占 2-3G，其他应用占 2-3G，剩下 26G 左右可以给 buffer pool。保守点设 20G（约 60%），激进点设 24G（约 75%）。

**验证方法**：查 `Innodb_buffer_pool_reads`（从磁盘读的请求数）和 `Innodb_buffer_pool_read_requests`（总读请求数）。两个数的比值叫"磁盘读取率"。如果超过 5%，说明 buffer pool 不够大，大量读请求还是在走磁盘。

### PostgreSQL：shared buffers 和 work_mem


`shared_buffers` 是共享缓冲区，类似 MySQL 的 buffer pool。**默认值**：128MB。**生产建议**：内存的 25%-40%。PostgreSQL 的 shared buffers 不建议设太大（超过 40% 收益递减），因为 PostgreSQL 还依赖操作系统的 page cache。

`work_mem` 是单个查询排序/哈希操作可用的内存上限。**默认值**：4MB。这个值太小了。排序一个大表、做哈希连接，4MB 根本不够，数据库会把中间结果写到磁盘上临时文件。

**注意**：`work_mem` 不是全局限制，是每个查询每次排序/哈希操作的内存。如果一个查询用了 3 个排序操作，它可能消耗 3 × work_mem。如果同时有 100 个连接在跑，总内存消耗可能高达 100 × 3 × work_mem。所以这个值不能设太大，一般 64MB-256MB 比较安全。

### 踩坑提醒


>我曾经见过一个团队把 `innodb_buffer_pool_size` 设到了 30G，但服务器总共就 32G。结果操作系统内存不够，开始 swap（用磁盘当内存），整个系统反而比设 20G 的时候慢了好几倍。内存参数不能贪心，要留余量。


----

## 02 连接参数——不是越多越好


很多人以为 `max_connections` 设得越大越好，觉得设大了总不会出问题。

事实相反。每个数据库连接都要占用内存（MySQL 每个连接约 2-5MB，PostgreSQL 每个连接约 10MB）。连接数设得太大，连接全满的时候内存就爆了。

### MySQL：max_connections 和 timeout


`max_connections`：**默认值**：150。**生产建议**：根据实际并发调整，一般 500-2000。设之前先问自己：应用层实际有多少个活跃连接？如果连接池配的是 50 个连接，`max_connections` 设 5000 没意义。

`wait_timeout` 和 `interactive_timeout`：连接空闲多久自动断开。**默认值**：28800 秒（8 小时）。太长了。一个连接空闲 8 小时才断开，意味着泄漏的连接要等 8 小时才能被清理。

**生产建议**：`wait_timeout` 设 600-1800 秒（10-30 分钟），配合连接池的健康检查，能及时回收泄漏的连接。

### PostgreSQL：max_connections 和 superuser_reserved_connections


`max_connections`：**默认值**：100。对于生产环境偏低，一般建议 200-500。PostgreSQL 的连接是进程模型（每个连接一个操作系统进程），内存开销比 MySQL 更大，所以连接数不宜设得太高。如果需要大量连接，建议用连接池（PgBouncer）在中间层做复用。

`superuser_reserved_connections`：保留给超级用户的连接数，防止普通连接打满后 DBA 也登不进去。**默认值**：3。建议保留，不要改成 0。

### 踩坑提醒


>连接数的最佳实践不是"数据库能撑多少"，是"应用层需要多少"。先查应用层连接池的配置（HikariCP 的 maximumPoolSize、Druid 的 maxActive），确认实际并发连接数，再倒推数据库的 `max_connections`。数据库端的值比连接池总和大 20%-50% 做余量就够了。


----

## 03 WAL/日志参数——数据安全的关键


WAL（Write-Ahead Log，预写式日志）是数据库保证数据不丢的机制。写数据之前先写日志，即使数据库突然崩溃，重启后也能通过日志恢复。

### MySQL：redo log 和 binlog


`innodb_log_file_size`：redo log 文件大小。**默认值**：48M。太小了。redo log 是环形的，写满了就要做 checkpoint（把脏数据刷盘）。redo log 越小，checkpoint 越频繁，刷盘开销越大。

**生产建议**：1G-4G。如果写入量大（每秒几百个事务），可以设到 4G。

`sync_binlog` 和 `innodb_flush_log_at_trx_commit`：这两个参数控制数据刷盘的频率，决定了"崩溃后能丢多少数据"。


|组合|`innodb_flush_log_at_trx_commit`|`sync_binlog`|安全性|性能|
|:-:|:-:|:-:|:-:|:-:|
|最安全|1（每次事务刷盘）|1（每次事务刷盘）|崩溃不丢数据|写入最慢|
|折中|1|0（OS 控制）|可能丢少量 binlog|中等|
|最快|0（OS 控制）|0|崩溃可能丢 1 秒数据|最快|

**生产建议**：核心业务（金融、支付）用最安全组合，可以接受的场景用折中方案。不要用最快组合，丢数据的风险远大于性能提升。

### PostgreSQL：WAL 和 checkpoint


`wal_level`：WAL 日志记录的详细程度。**默认值**：`replica`。如果需要逻辑复制，要改成 `logical`。

`max_wal_size`：WAL 文件的最大累积大小。**默认值**：1GB。写入量大时建议调到 4-8GB，减少 checkpoint 频率。

`checkpoint_completion_target`：checkpoint 完成的时间占比。**默认值**：0.9。意味着 checkpoint 要用 90% 的 checkpoint 间隔来完成刷盘，避免一次性把磁盘打满。这个值一般不需要改。

### 踩坑提醒


>有一个项目线上突然慢了几分钟，排查发现是 checkpoint 触发了大量刷盘，磁盘 I/O 被打满了。原因是 `max_wal_size` 设得太小（1GB），写入量大时 checkpoint 频繁触发。调大 `max_wal_size` 到 4GB，同时把 `checkpoint_completion_target` 保持在 0.9，问题消失。


----

## 04 查询优化器参数——让数据库更聪明


数据库优化器需要根据统计信息做决策。如果统计信息不够准，或者优化器的"胆量"设得不对，就会选错执行计划。

### MySQL：optimizer_switch 和 eq_range_index_dive_limit


`eq_range_index_dive_limit`：IN 列表的索引选择策略阈值。IN 列表短的时候（少于这个值），优化器会实际去索引里"潜水"（index dive）估算行数，结果准但慢。IN 列表长的时候（大于等于这个值），优化器用统计信息估算，快但不准。

**默认值**：200。一般不需要改。但如果业务有超长 IN 列表（比如 IN 后面跟几千个值），可能需要调大这个值，让优化器更精确地估算。

### PostgreSQL：default_statistics_target 和 random_page_cost


`default_statistics_target`：ANALYZE 命令收集统计信息时的采样精度。**默认值**：100。对于数据分布不均匀的大表，调到 500-1000 可以显著提升统计信息的准确度。

`random_page_cost`：优化器估算随机 I/O 的代价。**默认值**：4.0。这个值是基于机械硬盘的假设。如果数据库用 SSD，随机 I/O 和顺序 I/O 的代价差异不大，建议调到 1.0-1.5。

**为什么重要**：如果 SSD 服务器上 `random_page_cost` 还是默认的 4.0，优化器会高估随机 I/O 的代价，倾向于走 Seq Scan 而不是 Index Scan。结果是明明有索引，优化器不用。

### 踩坑提醒


>一个 SSD 服务器上 SQL 查询走了全表扫描，大家以为是索引建错了。查了半天发现是 `random_page_cost` 还是默认的 4.0，优化器认为走索引的随机 I/O 代价太高，宁可全表扫。改成 1.1 后，优化器立刻走了索引扫描，查询从 5 秒变成 50ms。


----

## 对比：开发/测试/生产环境参数差异


|参数|开发环境|测试环境|生产环境|
|:-:|:-:|:-:|:-:|
|buffer pool / shared_buffers|默认（够用就行）|中等（接近生产）|内存的 60%-70%|
|max_connections|150-200|300-500|按实际并发 + 20% 余量|
|wait_timeout|不关心|3600 秒|600-1800 秒|
|redo log / WAL size|默认|512MB-1GB|1-4GB|
|sync_binlog / flush_log|0（最快）|0 或 1|1（最安全）|
|random_page_cost|不关心|4.0（默认）|机械盘 4.0 / SSD 1.1|
|statistics_target|不关心|100（默认）|按数据分布调整（500-1000）|

>**核心认知**：测试环境参数越接近生产，测试结果的参考价值越大。很多性能问题在测试环境没发现，就是因为测试环境用的是默认参数，和生产环境差太远。


----

## 决策框架：按 workload 类型给参数基线


### OLTP 场景（在线交易，短查询、高并发）


|参数|建议值|
|:-:|:-:|
|buffer_pool|内存 60%-70%|
|max_connections|500-2000|
|innodb_log_file_size|1-4GB|
|sync_binlog + flush_log|1 + 1|
|random_page_cost（PG）|SSD 1.1 / 机械 4.0|

**核心思路**：内存优先给 buffer pool，减少磁盘读。连接数够用就行，不要贪多。刷盘策略选最安全的，交易数据不能丢。

### OLAP 场景（分析查询，大扫描、复杂聚合）


|参数|建议值|
|:-:|:-:|
|buffer_pool|内存 50%-60%（留内存给排序/哈希）|
|work_mem（PG）|256MB-1GB|
|max_connections|50-200（并发查询少）|
|max_wal_size（PG）|4-8GB|
|statistics_target（PG）|500-1000|

**核心思路**：大查询需要更多 work_mem 做排序和哈希，buffer pool 可以少给一点（因为要扫全表，缓存命中率不高）。统计信息精度调高，优化器才能选对大表的执行计划。

### 混合负载（OLTP + OLAP 共存）


|参数|建议值|
|:-:|:-:|
|buffer_pool|内存 50%|
|max_connections|300-500|
|work_mem（PG）|64-128MB（别太大，OLTP 查询多）|
|innodb_log_file_size|2-4GB|
|random_page_cost（PG）|SSD 1.1|

**核心思路**：OLTP 和 OLAP 争抢资源。buffer pool 折中，work_mem 别太大（防止 OLAP 大查询把所有内存吃掉）。如果 OLAP 查询很重，考虑把分析查询路由到只读副本，别和生产争资源。


----

## 从"参数就是填数字"到"参数是系统的一部分"


说实话，干 DBA 前三年，我对参数调优的态度是"照着网上的模板填"。别人说 buffer pool 设 70% 内存，我就设 70%。别人说 `work_mem` 设 64MB，我就设 64MB。

后来接了几个性能优化的项目才明白：参数没有标准答案。同样的参数，在 SSD 服务器上是好的，在机械盘上可能是灾难。同样的 `work_mem`，在 OLTP 场景下是合理的，在 OLAP 场景下可能太小。

这个认知转变让我重新理解参数调优的本质：参数不是"填数字"，是告诉数据库"你的运行环境是什么样的"。你告诉它用的是 SSD 还是机械盘、是 OLTP 还是 OLAP、数据量有多大、并发有多少——它才能做出最优的决策。

参数调优不是玄学，是把系统特征翻译成数据库能理解的参数。


----

## 深度分析：为什么"照着模板调参数"行不通？


网上有很多"生产环境参数模板"，拿来就能用。但实际用起来效果不一定好。

**根因在于**：参数模板假设了一个"标准生产环境"——16 核 64G、SSD、OLTP 负载、MySQL 8.0。但你的环境可能完全不同：8 核 32G、机械盘、混合负载、PostgreSQL 15。

更关键的是，参数之间存在联动关系。比如 `work_mem` 设大了，单个查询变快了，但如果并发查询多，总内存消耗可能爆掉。`innodb_log_file_size` 调大了，checkpoint 频率降低了，但崩溃恢复时间会变长。

**正确的做法是**：先搞清楚自己的系统特征（硬件、负载类型、数据分布、并发模式），再根据特征调整参数。每调一个参数，都验证一下效果——不是看数据库能不能跑，是看关键指标（buffer pool 命中率、慢查询数量、磁盘 I/O 利用率）有没有改善。

>这个思路和 DBA 的日常建议一致：没有银弹参数，只有理解你的系统后做出的合理调整。


----

## 参数调优验证清单


调完参数后，按这个清单逐项验证：

**1. 内存验证**


- buffer pool 命中率 > 95%（查 `Innodb_buffer_pool_read_requests` vs `Innodb_buffer_pool_reads`）

- 系统剩余内存 > 2GB（确认没有内存紧张）

- 没有出现 swap 使用（`free -m` 看 swap 使用量）


**2. 连接验证**


- 实际连接数 < max_connections 的 80%

- 空闲连接能被 timeout 正常回收

- 超级用户保留连接数 >= 3（DBA 能随时登进去）


**3. 日志/WAL 验证**


- redo log / WAL 使用率 < 80%（没被打满）

- checkpoint 间隔合理（不会频繁触发刷盘）

- 刷盘策略符合业务安全要求


**4. 优化器验证**


- 关键 SQL 的执行计划正确（没有不合理的 Seq Scan）

- 统计信息是最新的（跑过 ANALYZE）

- 慢查询数量在调参后有明显下降


**5. 压力验证**


- 用生产环境同等并发压测，确认参数在峰值下也稳定

- 峰值时内存不爆、连接不满、磁盘不卡


----

## 总结


数据库参数调优就一套流程：**了解系统特征 → 按 workload 类型设基线 → 逐项验证 → 压测确认。**

核心认知：参数不是"填数字"，是告诉数据库你的运行环境是什么样的。没有万能参数，只有和你的系统匹配的合理参数。

预防参数问题的关键：**内存留余量、连接不贪多、刷盘选安全、SSD 调 cost、统计要最新。**

调过上百个数据库的参数，每次回到这套流程，效果都能出来。不需要什么高级工具，理解原理和耐心验证就够了。

后续我会继续分享**数据库容量规划、迁移前 SQL 审计**这些话题，跟着我一篇篇学，数据库这块就没问题了。

有问题评论区见。


----

十五年数据库领域老炮。关注我，一起把数据库这件事搞明白。

十五年数据库相关经验，做过 DBA、架构师、技术顾问。不求"颠覆"，只求"靠谱"。

数据库默认参数能跑生产？别拿业务开玩笑

数据库参数调优四步法：内存、连接、WAL、优化器。不是"填数字"，是把系统特征翻译成数据库能理解的参数。附三档 workload 参数基线和验证清单。

数据库

运维

后端

数据库参数调优实战指南：从内存、连接、日志到优化器，详解MySQL和PostgreSQL核心参数配置。基于15年DBA经验，提供生产环境参数基线、踩坑案例和验证清单，帮助团队避免默认配置陷阱，提升数据库性能3倍以上。

数据库优化

数据安全

PostgreSQL

服务器

路由

MySQL

OLAP

OLTP

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

数据库默认参数能跑生产？别拿业务开玩笑-腾讯云开发者社区-腾讯云

数据库默认参数能跑生产？别拿业务开玩笑

数据库默认参数能跑生产？别拿业务开玩笑

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐