前两天和一个做数据库运维的朋友吃饭，他跟我吐槽了件事：他们公司最近接了个项目，客户的数据库动不动就报警，CPU 飙到 90% 以上，磁盘 I/O 直接打到极限，业务那边天天投诉系统卡得像蜗牛一样。他说，这活儿看着简单，但真正干起来才发现，数据库运维并不是装个监控、调几个参数就能搞定的。我听完笑了，这哪是吐槽，这分明是行业通病。做数据库运维的，谁没遇到过几个“祖传”数据库——历史包袱重、业务逻辑复杂、代码随心所欲，动不动就宕机。今天我就拿这个案例聊聊，数据库运维到底怎么落地，才能让项目真正跑起来。
案例的主角是一家中型电商公司，日均订单量在十万级别，库存、订单、用户数据全堆在一个 MySQL 实例里。刚接手时，监控系统显示，慢查询日志每天能刷出上千条，有些 SQL 执行时间超过十秒。我们团队第一步做的不是调优，而是先梳理问题。和业务方聊了一圈后发现，很多慢查询来自一个“历史遗留”的报表查询，每次跑都要扫描整张订单表，数据量已经超过两千万行。这就是典型的“业务逻辑没跟上数据增长”的问题。我们没有急着改代码，而是先建了几个合理的索引，把全表扫描的查询压下去。效果立竿见影，CPU 使用率从 90% 降到 60%，但这仍然是治标。
接下来，我们开始拆解数据库的读写压力。这个电商场景有个特点：白天读写混合，晚上跑批处理。白天高峰期，用户下单、查库存、看订单，都是高频操作，单实例扛不住并发。于是我们引入了读写分离架构，主库负责写，从库负责读。这一步说起来简单，落地时却踩了坑——业务代码里有些查询仍然落到主库，导致从库负载低得离谱，主库反而更忙。后来通过抓取 SQL 日志，逐个排查，把本应走从库的读请求全部纠正。同时，我们给从库加了延迟监控，确保数据同步在秒级以内，避免用户看到过期的订单状态。调整后，主库的 QPS 从峰值的 5000 降到 2000，系统稳定多了。
但问题还没完。电商促销活动一来，流量瞬间翻倍，数据库再次吃不消。我们决定引入缓存层，用 Redis 把热点数据缓存起来，比如商品库存、用户购物车、订单状态。思路不新鲜，关键在于缓存策略的设计。库存数据我们采用“先更新数据库，再删除缓存”的模式，避免并发更新导致缓存与数据库不一致。为防止缓存雪崩，给热点 key 设置了随机过期时间。最头疼的是订单状态变更——用户下单后，状态从“待支付”变成“已支付”，必须实时同步到缓存，否则用户会以为订单未成功。我们写了一个监听 binlog 的组件，把数据库变更实时推送到 Redis，确保最终一致性。上线后，数据库的读请求压力降低了 70%，高峰期 CPU 稳定在 30% 以下。
当然，数据库运维不只是技术活，还涉及与开发团队的协作。项目中我们发现大量“僵尸 SQL”——一些查询在代码里写了却根本不被调用，或者调用频率极低，却占用了连接池。于是我们和开发开会，把慢查询日志导出来，逐条分析哪些 SQL 可以优化，哪些可以直接删掉。开发最初有点抵触，觉得改代码麻烦。我们就拿数据说话：某条 SQL 执行一次要扫五百万行，耗时二十秒，而一天只被调用三次，典型的“费力不讨好”。他们同意删掉这条 SQL，改为定时任务离线处理。这种“砍掉无用查询”的做法，比单纯调参更直接有效。
还有一个容易被忽视的坑：数据库的备份和恢复。项目初期使用的是物理备份，每周一次全量、每天一次增量。一次业务表误删字段，导致业务停了半小时。复盘后发现，物理备份恢复太慢，需要先恢复全量再应用增量，整个过程要两小时。于是我们改为逻辑备份，每天凌晨跑一次 mysqldump，把关键表单独备份，并编写了自动化恢复脚本，能在十五分钟内把误删的数据恢复。备份平时看似不重要，真出事时却是救命稻草。
我们为项目建立了“数据库健康体检”的常态化机制。每个月跑一次性能分析，查看慢查询趋势、索引使用率、磁盘空间增长、连接数峰值等。比如磁盘空间，我们提前设定告警阈值，使用率超过 80% 时自动触发扩容脚本，避免因磁盘写满导致崩溃。还有一次发现某表索引碎片率高达 40%，重建索引后查询性能提升了 30%。常态化运维的好处在于，问题在萌芽阶段就被掐死，而不是等到业务投诉才去救火。
回头看看这个项目，从接手时的“三天一小挂、五天一大挂”，到后来稳定运行半年未出现一次事故，靠的不是某个“大招”，而是一系列小细节的累积。数据库运维本质上是个“慢工出细活”的活儿，不能指望装个监控工具就高枕无忧，也不能指望一次调优就一劳永逸。它需要你不断与业务对齐需求，跟开发磨合流程，跟数据本身较劲。那些看似琐碎的索引优化、缓存策略、备份方案，才是真正让数据库跑得稳的核心。如果你现在也在做数据库运维，别总想着找“银弹”，先把眼前的慢查询干掉，把不合理的连接池配置改掉，把缺失的备份脚本补上。这些小事做好了，数据库自然不会掉链子。
