周五晚上十点业务群里的消息像炸了锅一样弹出来订单查询接口超时、连接池打满、MySQL CPU 占用率持续飙升到 100%。打开监控一看一个跑了两三年的业务库QPS 从平时的两三千突然飙到两万慢查询日志里冒出了一批之前没见过的新面孔。那晚我花了四个小时从上到下捋了一遍系统第二天又花了一整天做索引调整和参数优化才把这个即将被流量冲垮的库从悬崖边拉了回来。事后我把整个过程整理成了这套调优笔记从底层硬件讲到 SQL 写法再到最终的主从复制架构升级一条线串下来你会发现调优没那么玄乎关键是得按顺序来。这篇内容就是给你一份可落地的 MySQL 调优实战手册。不管你是刚接手项目开发、经常被慢查询折磨的后端工程师还是负责数据库稳定性的运维人员只要能跟着把每个环节过一遍基本都能把系统的性能瓶颈找出来、按得住。我不打算堆一长串参数让你盲目复制每个关键配置我都会讲清楚它为什么这么设、算出来是多少、改了之后会怎样。1. 调优这件事先搞清楚顺序再动手调优最怕的不是不懂参数而是上来就乱改配置。我做过的几次大型调优包括那次救火最后沉淀下来的方法论基本是一致的先看整体、再定位局部、最后才动手调。1.1 瓶颈到底在哪一层很多人一遇到数据库卡顿第一反应就是去翻配置文件把 buffer pool 调大一点、连接数调高一点结果往往收效甚微甚至把系统调得更不稳定。其实一个完整的数据库请求路径是这样的应用发 SQL - MySQL 服务层解析 - 存储引擎读写 - 操作系统调用 - 硬件磁盘读取。任何一个环节掉链子都会表现为查询变慢但根因可能差了十万八千里。我习惯把调优分成四个层级像漏斗一样一层一层筛第一层业务 SQL 层。有没有烂 SQL、缺索引、大事务、跨秒级长事务这是性价比最高的排查点。第二层MySQL 服务层。连接数够不够、线程池状态、查询缓存命中率、临时表使用情况反映的是数据库自身的运行状态。第三层InnoDB 存储引擎层。缓冲池命中率、日志刷盘策略、锁等待、脏页刷新这些直接决定数据读写效率。第四层操作系统与硬件层。磁盘 IOPS、CPU 负载、内存带宽、swap 使用属于最底层的基础设施。排优先级的时候先查 SQL 和索引再调 MySQL 参数最后才考虑换硬件或动架构。有一次排查一个跑批极慢的问题DBA 把innodb_buffer_pool_size调到了物理内存的 80%结果系统开始频繁 swap反而更慢了。后来定位到是一条 2000 万行的表上没有时间索引加完索引跑批时间从 40 分钟降到了 3 分钟。这就是典型的舍本逐末。1.2 监控数据要先行调优的第一步不是调而是拿到现状数据。建议任何一次调优开始前先做一轮至少一周的监控采集。我自己一直用的是 Prometheus mysqld_exporter Grafana 这套组合采集 MySQL 的 QPS、连接数、慢查询数量、InnoDB 缓冲池命中率、磁盘 IO 等核心指标。拿到监控数据之后你会很清楚地看到几个关键事实高峰期是几点、QPS 峰值多少、慢查询有没有规律性、buffer pool 命中率是否长期低于 99%、磁盘使用率是不是经常打满。这些数据就是你判断瓶颈在哪一层的依据也是调优之后对比效果好坏的基准线。没有这个基线你根本不知道改动是变好了还是变坏了。另外一个容易被忽略的细节是调优是一次性的但监控是持续的。同一套监控系统调优完成后继续跑着一旦有问题能第一时间在曲线图上看到异常拐点。这也是那次救火行动里我能快速定位问题的关键因为历史数据都在一对比就知道当前曲线的形态和平时完全不同。2. 硬件与系统层是地基先把它夯实MySQL 再怎么优化最终所有数据读写都要落到硬件上。如果底层基础设施本身就存在短板再好的参数配置也只是在沙地上盖楼。2.1 CPU、内存与磁盘的选型逻辑CPU 方面存在一个常见的误区以为核数越多越好。对于 MySQL 这种高并发 OLTP 场景单核性能往往比核数更关键因为 InnoDB 内部有很多全局锁和缓存争用核数太多反而会增加上下文切换开销。生产环境如果 QPS 要求不高选 8 到 16 核、主频 3.0GHz 以上的 CPU 通常就够了。内存是最值得花钱的部分。MySQL 的 InnoDB 引擎设计上就是把数据页缓存在内存里内存越大磁盘读取的次数就越少。一条简单经验如果数据总量在 200GB 以内innodb_buffer_pool_size直接按物理内存的 60% 到 70% 分配数据量特别大、远超内存的至少也让热数据绝大部分落在内存中。有一个判断方法看information_schema.TABLES统计出来的数据总量再对比实际查询的活跃数据范围热数据占比高buffer pool 就得配够。磁盘选择上用 NVMe SSD 已经是共识了。随机读写性能上NVMe 比 SATA SSD 高一个数量级比机械硬盘高两个数量级。之前我们有一批老机器用的是 7200 转机械盘跑一个 50GB 的报表库每个聚合查询都要 30 秒以上。后来迁移到 NVMe同样的查询基本都在 5 秒内完成。硬件升级给性能带来的提升经常比调参数来得更直接。2.2 操作系统层面的三个必调项Linux 系统默认配置是为通用场景设计的装完 MySQL 之后有几个参数必须手工调整否则某些情况下会出现意想不到的问题。第一个是swappiness。默认值是 60表示内存压力较大时系统会比较积极地使用 swap。对数据库服务器来说swap 就是性能杀手因为内存页换到磁盘之后InnoDB 每次访问这些页都要走一遍磁盘 IO。我会在部署 MySQL 的机器上把vm.swappiness调到 1甚至直接改成 0让系统尽量不主动使用 swap。第二个是关闭 Transparent Huge PagesTHP。这个特性虽然能提升内存分配效率但会导致内存页大小不固定InnoDB 的内存分配机制和它不对付容易引发性能抖动。网上很多排查案例里提到的数据库响应忽快忽慢最后定位到就是 THP 在作怪。关闭方法是在/etc/rc.local里写入echo never /sys/kernel/mm/transparent_hugepage/enabled然后重启生效。第三个是文件描述符限制。默认的ulimit -n通常是 1024而 MySQL 在高并发下需要打开的文件数远超这个值。要在/etc/security/limits.conf里给 mysql 用户设置nofile为 65535 或更高。否则连接数一涨MySQL 会报 Too many open files连接直接失败。这些系统层的调整做完之后再回头看 MySQL 本身前面那些参数才有意义。3. 配置参数调优抓住最核心的三件套MySQL 的配置参数动辄上百个真正常需要调整的其实就那么十几个。其他大部分参数保持默认值反而更安全改错了容易引发不可预期的问题。社区里流传的参数调优三件套指的就是innodb_buffer_pool_size、innodb_log_file_size和innodb_flush_log_at_trx_commit。这三兄弟决定了 InnoDB 最大的内存缓存、崩溃恢复能力和数据安全级别是任何调优都绕不开的起点。3.1 innodb_buffer_pool_size最值钱的那一部分内存这个参数决定 InnoDB 缓存数据页和索引页的内存池大小。它几乎是所有 MySQL 调优的第一着手点因为它直接决定有多少读操作能命中内存从而避免磁盘 IO。设置方法不应该是拍脑袋而是有个计算依据。假设物理内存 32GB数据总量约 80GB查询热点集中在最近 30% 的数据约 24GB那么 buffer pool 至少要给到 24GB 才能保证热数据全在内存。再加上 MySQL 其他部分和操作系统要预留约 20% 内存32GB 的机器给 22GB 到 24GB 是比较合理的选择。如果数据总量远大于内存比如 1TB 数据只有 64GB 内存那 buffer pool 64GB 机器给 40GB 左右也够了因为无论给多少总会有一部分数据在磁盘上关键是热点能落在缓存里。实际操作中可以分多次调整每次增加 2GB 到 4GB观察一段时间内的Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads两个状态值。读命中率 读请求次数 / (读请求次数 实际读磁盘次数)长期低于 99% 就说明缓存不够用需要继续加大。3.2 redo log 大小决定了写入吞吐很多人在调优时容易忽略innodb_log_file_sizeMySQL 8.0 里对应的是innodb_redo_log_capacity但它对写入性能的影响非常显著。redo log 是 InnoDB 的 WALWrite-Ahead Logging机制里用于崩溃恢复的日志它的容量决定了崩溃后最多能恢复到什么时间点。redo log 太小的话日志切换和刷盘会变得非常频繁产生大量小 IO写入吞吐上不去。默认的 48MB8.0 之前的 5.6/5.7 默认是 48M对稍大点的业务来说明显偏小。我把这个值调成 1GB 甚至 2GB 之后常见的批量插入场景性能能提升 30% 以上。具体怎么选一个经验公式是innodb_log_file_size最好能覆盖至少一小时的写入量。你可以通过SHOW ENGINE INNODB STATUS\G查看Log sequence number的推进速度粗略估算每小时产生多少日志然后让日志容量至少能容纳这个量。这里的判断逻辑是日志空间够大刷盘频率就低写入能力就强副作用是崩溃恢复时间变长但相比性能提升这个代价通常可以接受。3.3 刷盘策略与一致性的权衡innodb_flush_log_at_trx_commit有三个取值0、1、2。设为 1每次事务提交都要将 redo log 刷到磁盘最安全每次提交都落盘性能最差。设为 0每秒刷一次盘崩溃时最多丢失 1 秒数据性能最好。设为 2每次提交只写入操作系统缓存也是每秒刷盘崩溃时丢失数据量取决于操作系统是否宕机性能接近 0安全性居中。大多数金融类、订单类业务必须用 1保证事务不丢。但对于日志、埋点、统计类业务用 2 甚至 0 可以换来数倍的写入性能。调这个参数本质上是对数据安全性和写入性能做权衡你必须清楚自己业务的容忍度。我一般建议外部不可见的内部系统用 2面向用户的交易系统用 1用 0 的场景非常少。如果设了 1建议把sync_binlog也同步设为 1这样每次事务提交时 redo log 和 binlog 都落盘不会出现两者不一致导致主从数据错乱的情况。3.4 连接数、线程并发与临时表max_connections是另一个高频调整项。默认值是 151但生产环境经常需要调大。判断依据是监控你的连接数曲线如果Threads_connected经常超过 200说明 151 不够。但注意连接数不是越大越好每个连接都要占用线程资源MySQL 的并发能力是有限的连接数设到 3000 并不代表它能同时服务 3000 个请求。更合理的做法是应用层做好连接池让活跃连接数维持在几十到几百之间用池化复用连接而不是每次都新建。innodb_thread_concurrency这个参数也值得一提。默认 InnoDB 允许 64 个并发线程同时进入内核超过的会排队等待。服务器核数越多这个值可以适当调大比如 32 核机器设成 64 或 128。如果出现大量线程堆积、CPU 却跑不满的情况说明这个值设小了。tmp_table_size和max_heap_table_size是容易被忽视的。当 SQL 中需要排序或分组、且结果集超过这两个值时MySQL 会把临时表从内存转写到磁盘性能急剧下降。我遇到过一条普通分组查询结果集 200MB默认 16MB 临时表直接落盘查询耗时从 1 秒变成 20 秒。把这两个值设成 64MB 或 128MB 之后问题立刻消失。不过也别设太大否则内存会被大量并发查询的临时表占满。修改参数的时候要记住SET GLOBAL只对当前实例临时生效重启就没了要持久化必须写进my.cnf。另外 8.0 之后用SET PERSIST可以直接持久化但建议还是以配置文件为最终依据方便统一管理和回溯。4. SQL 与索引优化是性价比最高的一环很多慢查询问题根本不需要动架构光是优化 SQL 就能带来成倍性能提升。这也是我调优时最先动手的部分因为投入最小、产出最快。4.1 开慢查询日志掌握第一手资料调优 SQL 的第一步是找到那些拖后腿的查询。如果还没开慢查询日志先去my.cnf里把下面这几项加上slow_query_log 1 slow_query_log_file /var/log/mysql/slow.log long_query_time 1 log_queries_not_using_indexes 1long_query_time设成 1表示超过 1 秒的查询都记录下来。日志会越攒越多建议配合pt-query-digest或内置的mysqldumpslow做汇总分析找出 TOP N 慢查询。我每次做排查第一件事永远是看这个文件因为它直接告诉你哪些 SQL 在拖系统后腿。有一次线上故障慢查询日志里出现大量同一模式的 SQL都是SELECT * FROM orders WHERE status 1 ORDER BY create_time DESC LIMIT 10。结果集不大但status字段区分度极低只有 0、1、2 三种值导致这个查询全表扫了 900 万行。这种就是典型的索引失效型慢 SQL。4.2 explain 怎么看索引怎么设计拿到慢 SQL 之后用EXPLAIN分析执行计划。重点看这几个字段type从好到差依次是 system - const - eq_ref - ref - range - index - ALL。看到ALL说明全表扫描基本可以断定有问题。rows预估扫描行数数值越大越危险。Extra看到Using filesort说明排序用到了临时文件看到Using temporary说明用到了临时表这两个都是我优先解决的目标。索引设计有几个核心原则是先写死不能违背的最左前缀原则。联合索引(a, b, c)能匹配a、(a, b)、(a, b, c)但不能单独匹配b或c。设计联合索引时要按区分度高低、查询频率排好顺序。覆盖索引。让查询的列都在索引中避免回表。SELECT id, name FROM user WHERE status1如果(status, id, name)是一个联合索引那么查询直接走索引就能拿到全部结果不需要回表。不要滥用索引。写多读少的表索引多了不仅浪费磁盘还拖慢写入。一个表索引数尽量控制在 5 个以内。隐式转换是索引杀手。WHERE phone 13800000000如果phone是 varchar 类型MySQL 会把字符串转成数字再比较索引直接失效。字段类型和查询条件类型要对齐。4.3 常见的慢 SQL 改写套路LIKE %keyword%是最常见的索引失效场景之一。因为前导模糊无法使用 B 树索引解决方案是改用全文索引或把查询逻辑拆成等值条件加后缀模糊LIKE keyword%再不行就在应用层做分词搜索。OR条件也要特别小心WHERE a 1 OR b 2在 MySQL 里如果a和b都有索引优化器可能还是会扫描全表。改写思路是用UNION ALL拆成两个查询。深分页LIMIT 100000, 20是另一个大坑MySQL 会先扫描前 100020 行再丢弃前 10 万行。优化方式是用上一页的最大 ID 做游标WHERE id 上一页最大ID ORDER BY id LIMIT 20这样每页只扫 20 行速度天差地别。还有批量更新时不要一次更新几百万行拆成每 1000 行一提交的小批次。一次大事务会持有大量行锁和 undo log长事务还会把 binlog 撑大影响主从延迟。把事务拆小是写入场景里最实用的一招。这些 SQL 层面的优化做完之后如果你发现已经到了数据库单机能力的上限比如 CPU 长期在 80% 以上、磁盘 IO 饱和那就可以考虑下一步架构升级。5. 架构升级从单机到主从复制再到读写分离单机 MySQL 再能打也有个天花板。我曾经维护过一个库单机配置很好32 核 CPU、128GB 内存、NVMe SSD但到 QPS 接近 8000 的时候CPU 排队、锁等待、磁盘 IO 三项指标同时报警。这个时候再调参数已经作用不大了正确方向是架构升级。5.1 什么时候该考虑升级架构我的判断标准很简单出现以下任意一条就说明该做架构改造了单机 CPU 长期超过 70%即使调完参数和 SQL 也没有明显下降。磁盘容量或 IOPS 已经接近上限数据规模还在持续增长。业务对高可用有要求无法容忍数据库单点故障的宕机风险。备份操作严重影响线上性能因为单机上备份会争抢 IO 资源。架构升级一般按这个路线走先加缓存减少数据库压力 - 再做主从复制解决高可用和备份压力 - 然后做读写分离扩展读能力 - 最后才考虑分库分表。每一步都是一次投入产出比的权衡。5.2 主从复制搭建的要点主从复制是最实用、门槛最低的架构升级方案。核心配置在主库上开启 binlog 并设置server-id[mysqld] server-id 1 log-bin mysql-bin binlog_format ROW从库上设置[mysqld] server-id 2 read_only 1然后从库执行CHANGE MASTER TO指定主库的 binlog 文件和位置或者直接用 GTID 模式自动同步。之后START SLAVE通过SHOW SLAVE STATUS\G查看Slave_IO_Running和Slave_SQL_Running是否都为Yes。这里有几个细节特别重要binlog_format ROW虽然生成日志量大但比 STATEMENT 更安全不会出现函数、触发器在主从执行结果不一致的问题。新版本 MySQL 推荐直接开 GTID主从切换、故障恢复会简单很多。从库别只读是不允许的read_only1只能挡住应用层连接super权限依然能写要注意账号权限。5.3 读写分离与中间件选型有了主从之后通常紧接着就是读写分离写操作走主库读操作分摊到从库。实现方式有两种一种是在应用层通过动态数据源做读写分离适合小团队快速实现另一种是引入中间件让业务层无感知地路由 SQL。我做过的项目里读多写少、QPS 高的大服务用中间件居多。目前主流选择是 ShardingSphere 和 ProxySQL。ShardingSphere 偏 Java 生态与应用集成度高功能包括读写分离、分库分表、数据脱敏等ProxySQL 是独立的代理层支持复杂的查询路由规则对业务透明适合混合技术栈。考虑到成本和学习曲线如果团队规模不大我建议先让应用层接两个数据源实现读写分离跑一段时间稳定之后再考虑要不要引入中间件。架构不是越复杂越好每引入一个组件运维成本就涨一截。5.4 分库分表的触发点与常规做法分库分表是最后的手段因为一旦拆分全局 ID、跨库关联查询、分布式事务都会变成新的麻烦。触发它的硬指标一般是单表数据量超过 1000 万到 2000 万、表容量超过 200GB或者单表 QPS 已经扛不住了。注意不是说到了这些数据就必须拆如果你的查询都能命中索引且没有全表扫单表几千万行也能跑得动。分片策略上range分片按时间切分适合日志、订单类有明确时间维度的数据hash分片按业务主键均匀散列适合访问热点不确定的场景。订单表我见过很多按用户 ID 哈希分片的因为订单查询基本都带上用户维度。加上一个全局 ID 生成器雪花算法或者数据库分段发号就能解决大多数拆分后的 ID 问题。拆完之后你还会面临跨分片聚合、排序、分页的难题所以很多团队会把聚合查询交给 ClickHouse 或 Elasticsearch 这类分析型组件去做。一般来说主库 MySQL 只负责 OLTP 的点查和写入分析需求单独走数仓链路。这条路走通之后数据库的承载能力基本能扩展一个数量级以上。6. 调优工具与一次真实故障排查实录不装一堆看起来很厉害的监控面板调优最终要靠几个趁手的命令行工具和扎实的排查思路。我日常用的工具箱不那么花哨但每一个都在关键时刻起过作用。6.1 我的日常调优工具清单mysqltunerPerl 写的体检脚本跑一次能给出 buffer pool、连接数、临时表等几十项建议虽然不完全准确但用来快速摸底非常高效。pt-query-digest分析慢查询日志的利器按总耗时、平均耗时、出现次数排序能快速找出 TOP N 慢 SQL。sysbench压测工具做参数调整前后的对比测试用它来验证改动是正优化还是负优化。SHOW ENGINE INNODB STATUS\G不需要装额外工具直接查看 InnoDB 的内部状态包括锁等待、脏页刷新、redo log 使用情况、历史链接等。真正调优的时候我的工作流一般是mysqltuner扫一遍拿到整体面 -pt-query-digest分析慢 SQL 找具体问题 -SHOW ENGINE INNODB STATUS看引擎层细节 - 改完配置或 SQL 之后用sysbench压测 对比监控曲线。6.2 一次真实故障的完整排查过程那次救火行动的排查记录我觉得特别值得拿出来讲讲。事情发生时监控显示主库 CPU 100% 持续了将近十分钟应用层不断报数据库连接超时。我先打开SHOW PROCESSLIST发现几十条会话卡在同一个状态的查询上而且执行时间都超过 30 秒。用EXPLAIN查看这条卡住的 SQL发现它跑在一张 900 万行的order_item表上type是ALLrows预估 890 万行Extra里还有Using filesort。当时这个查询是后台任务扫描未支付且超过 24 小时的订单因为status和create_time都没建合适的联合索引导致每次任务跑起来都要全表扫一遍。定位之后的操作分两步。第一步立刻加索引ALTER TABLE order_item ADD INDEX idx_status_create_time (status, create_time)然后后台任务重跑单次执行时间从 35 秒降到 0.8 秒。第二步回头检查为什么之前会漏掉这个索引发现是业务上线新功能时新加了status字段但 DBA 没有同步 review 新增查询的执行计划。这就是一个典型的人为流程漏洞光靠调优救火是救不完的要建立上线前的 SQL 审核机制。同一天晚上我还发现主库的innodb_log_file_size偏小日志每 20 秒切换一次刷盘频率过高导致写入吞吐被压制。重启后把日志容量加大到 1GB写入性能提升了大约 25%。6.3 排查过程中的几个重要误区和心得踩过的坑多了反而能沉淀出几条真正有价值的经验。第一不要只盯着慢查日志看。很多慢查询是偶发的平时跑得挺快高峰期并发一高就崩。performance_schema里的events_statements_summary_by_digest表记录了所有 SQL 的聚合统计按总延迟排序就能找出平时快但总量大的隐性杀手。第二改参数之后必须观察至少 24 小时。一次参数改动可能在低峰期没影响一到高峰期原形毕露。我见过有人把max_connections从 200 调到 2000结果高峰期连接全挤在等待队列里数据库反而因为锁和上下文切换更慢。改完参数之后对比高峰期的 QPS、平均响应时间、连接数曲线才能判断改动是否正确。第三备份和调优之间要有平衡。开启 GTID 做主从复制之后从库可以做物理备份减轻主库备份压力。如果单库仍要做mysqldump全量备份建议错峰执行比如凌晨低峰期并加上--single-transaction参数避免锁表。第四关于参数调优三件套外界经常讨论的是innodb_buffer_pool_size、innodb_log_file_size、innodb_flush_log_at_trx_commit这三项。但我的实际体验是参数再优化也只是把机器的性能榨干真正让系统量变到质变的节点是架构升级。参数优化和架构升级不是二选一而是先后关系先用参数优化把单机榨到 70% 到 80% 的合理水位再靠架构升级突破单机上限。6.4 常见问题的速查表最后整理一份我在实际工作中经常遇到的问题速查表都是亲测有效的排查方向现象优先排查项常用命令/工具解决思路ERROR 2002 (HY000): Cant connect to local MySQL server through socketmysqld 进程是否存活、socket 路径是否正确ps -efgrep mysqld、netstat -tlnp 查看 3306too many connectionsmax_connections设置、应用连接池参数SHOW STATUS LIKE Threads_connected调大max_connections但更要确认应用层连接池是否有泄漏连接用后及时归还主从延迟持续增长binlog 大小、从库硬件性能、大事务SHOW SLAVE STATUS\G看Seconds_Behind_Master拆大事务、给从库升配、用并行复制slave_parallel_workers慢查询集中在同一张表表数据量、索引使用情况EXPLAINpt-query-digest补索引、优化 SQL、必要时做表分区或归档历史数据CPU 高但慢查不多全表扫描的扫描量太大或者 InnoDB 内部锁竞争、预热SHOW PROCESSLIST、SHOW ENGINE INNODB STATUS\G看 History list length检查是否热点行更新触发行锁等待考虑分散热点扫描量大的话结合慢查优化内存占用持续走高buffer pool 设置、连接数、临时表free -h、SHOW STATUS LIKE Created_tmp_disk_tables调低tmp_table_size上限控制临时表内存占用检查连接数是否异常堆积批量插入极慢redo log 过小、刷盘策略过严SHOW ENGINE INNODB STATUS\G看 log 切换频率调大innodb_log_file_size评估innodb_flush_log_at_trx_commit调成 2 的可行性查询速度时快时慢线上是否开启 THP、内存是否出现 swapcat /proc/sys/vm/swappiness、cat /sys/kernel/mm/transparent_hugepage/enabled关闭 THP、调低 swappiness、预留足够内存这张表本质上就是我对性能排查的心得汇总。遇到问题先对号入座按表格里的方向排查基本能覆盖日常工作中 80% 的 MySQL 棘手场景。最后再分享一个我在多次实战中验证过的思路调优从来不是一次性交付物而是一个持续演进的长期维护过程。每次业务发版、数据量变化、监控曲线异常都要回到这套方法论里重新走一遍——查慢 SQL、看执行计划、对比监控基线和压力测试结果。把优化的循环嵌入到日常运维节奏里比等系统出问题再救火要省心得多。你手头的数据库今天做一次全面的体检和调优明天遇到流量洪峰时就会从容很多。