这事儿得从一次线上事故说起。去年双十一，一个做电商的朋友半夜给我打电话，说他们后台的订单查询接口突然卡死了，每次请求都要等十几秒甚至超时。我远程连上去一看，数据库 CPU 飙到 99%，慢查询日志里全是一条 SQL——查订单时用了 ，这个 NOT IN 子查询要把黑名单表里几十万条数据全扫一遍，然后再和订单表做全表关联。当时我让他改成 ，并给相关列加索引，查询时间直接从 15 秒降到 0.3 秒。这哥们儿后来逢人就念叨：数据库调优不是玄学，是实打实的数学题。
很多人觉得数据库慢就去加硬件、换服务器，这其实是最懒的做法。调优的第一原则是：先看懂执行计划，再动手改代码。MySQL 用 ，PostgreSQL 用 ，这些工具就像汽车的仪表盘，告诉你 SQL 到底卡在哪儿。我见过最离谱的情况是，有个团队为了优化一个统计报表，花了两周时间调数据库参数，结果 一看，那个 SQL 根本没走索引，因为他们在 条件里对索引列做了函数运算——，这写法直接让索引失效。改成 ，查询时间从 8 秒降到 0.1 秒。调优第一步，永远是用工具找到瓶颈，而不是靠猜。
索引是数据库调优最核心的武器，但用不好就是双刃剑。复合索引的字段顺序特别讲究，原则是“把区分度高的放前面”。比如用户表有个索引 ，如果只查 ，这个索引基本废了，因为最左前缀原则限制了它。我见过一个案例：一个内容平台的文章表经常按分类查最新文章，他们建了 的复合索引，查询速度一直很 OK。但运营部门后来加了个功能，要按“文章标题关键词+分类”搜索，开发同学直接在现有索引上加了 ，结果全表扫描，每次查询都要 3 秒多。解决方案是单独建一个全文索引，把搜索和筛选分开处理，查询时间又回到毫秒级。索引不是越多越好，每个索引都要有明确的业务场景。
说到 SQL 写法，这里面全是细节。很多开发者习惯写 ，觉得省事，但在大表上这就是灾难。比如只需要查询用户 ID 和姓名，却用 把头像、个人简介、地址这些大字段也拉出来，不仅网络传输慢，还可能导致聚簇索引扫描变成二级索引扫描加回表。更狠的是 ，很多人在做随机推荐时喜欢用，但它会让数据库为每一行生成随机数再排序，数据量一上万就直接崩溃。我有个在线教育的客户，题库随机抽题功能以前用 ，题库只有 5000 道题，但每次请求都要跑 0.8 秒。后来改成程序随机生成 ID 范围再查询，时间直接压到 0.01 秒。调优很多时候就是跟这些“偷懒的写法”作斗争。
分库分表是很多人在数据量上升后第一反应，但这其实是“可选方案”，不是“最优方案”。我之前帮一个社交 App 做优化，他们的用户表有 3000 万条，查询变慢后，CTO 直接拍板分成 16 个库。结果分完之后，跨库查询、全局 ID 生成、数据迁移都成了新问题，团队花了三个月才勉强跑通。后来我建议他们先做缓存层，把用户基本信息放到 Redis，热点数据用本地缓存，数据库只负责写入和低频查询。配合读写分离，单表 3000 万条记录依然跑得飞快。分库分表会让架构复杂度急剧上升，除非单表数据量达到亿级，或写入吞吐量实在撑不住，否则别轻易动刀。
连接池和事务的配置也是调优里容易被忽视的环节。很多应用直接使用数据库的默认连接数，结果并发一上来，连接池满了，新请求排队等待，响应时间直线上升。合理设置连接池大小很关键，常用的经验公式是：，但具体数值需要压测才能确定。事务方面，很多人写着写着就忘了关闭自动提交，或者在一个事务里塞了太多无关操作。我见过一个支付系统，一个事务里同时做了订单创建、库存扣减、积分更新、短信发送，结果短信发送超时导致整个事务回滚，用户付了钱但订单没生成。正确的做法是事务只包含数据库操作，外部服务调用放到事务之外。每个事务的时长最好控制在 100 毫秒以内，超过这个时间就要考虑拆分。
说说硬件和配置层面的调优，这往往是锦上添花，而非雪中送炭。很多人一上来就把 调到内存的 80%，但如果你有 100 GB 内存，buffer pool 设 80 GB，操作系统只剩 20 GB 给文件缓存，反而可能拖慢。更合理的做法是留出足够的内存给操作系统和文件系统缓存。还有一个容易被忽略的点：磁盘 I/O。如果数据库跑在机械硬盘上，随机读写性能只有 SSD 的十分之一甚至更低。我有个客户，数据库服务器的磁盘 I/O 利用率常年 95% 以上，换成 NVMe SSD 后，同样的 SQL 查询时间直接砍半。但要注意，硬件升级不能替代 SQL 优化，一个烂 SQL 再好的硬件也扛不住，就像一辆拖拉机换上 F1 轮胎，慢的还是慢。
回头再看数据库调优，本质上是“用空间换时间、用计算换存储”的博弈。每个调优动作都要回答三个问题：这项改动能带来多少性能提升？会引入什么副作用？业务场景是否真的需要这个级别的优化？比如给只读报表加索引，成本可以忽略不计；但在频繁写入的表上加索引，就可能影响写入性能。真正的调优高手不是会用多少工具，而是能在成本和收益之间找到最优解。下次数据库变慢时，别急着拍桌子骂 DBA，先打开 看看执行计划，也许答案就在那几行输出里。记住，好的数据库调优就像好的写作——少即是多，精准才是王道。
