上周三晚上十一点，我正窝在沙发上看剧，手机突然炸了——客户群里连续弹出几十条消息，全是“系统卡死了”“页面转圈三分钟”“订单提交失败”。我赶紧打开后台，CPU飙到 98%，数据库连接池已满，慢查询日志里只有一条执行了 47 秒的 SQL。那一刻，我脑子嗡的一声，整个人从沙发上弹起来，连拖鞋都没穿就跑向电脑。这种场景，做过后端或 DBA 的人应该都不陌生，数据库性能问题就像一颗定时炸弹，你不知道它什么时候会炸，但一旦炸了，就要全公司熬夜。
做技术这行久了，你会发现一个规律——大部分数据库性能问题，都不是突然冒出来的。它更像一个慢慢积累的过程，就像每天往水池里倒一杯水，等到某天水漫出来，你才意识到问题。我见过太多这样的案例：上线前压测跑得溜，上线后第一周正常，第二周偶尔超时，第三周直接崩了。为什么？因为数据量在涨，并发在涨，但 SQL 没变，索引没加，配置没调。很多团队把数据库当成黑盒子，觉得只要连上就能用，结果等到线上出事才急忙翻慢查询日志。说句不好听的，这叫“平时不烧香，临时抱佛脚”。
说到慢查询，这玩意儿简直是数据库性能问题的头号杀手。有一次我帮一个电商客户排查问题，发现他们的订单查询接口平均响应时间 3.8 秒。我一看日志，好家伙，一条 SQL 跑了 2.7 秒，占了整个请求的 70%。这条 SQL 长什么样？SELECT * FROM orders WHERE status='pending' AND createtime>'2023-01-01' ORDER BY createtime DESC LIMIT 20。表面上看没毛病，但仔细一查，status 字段没有索引，createtime 的索引是降序的，而查询条件是大于某个时间点，导致 MySQL 必须全表扫描。更绝的是，这个表已经有两千多万条数据。加了个联合索引后，查询时间从 2.7 秒降到 0.03 秒，前后只花了五分钟。你说这事儿难吗？不难。但为什么之前没人做？因为没人去看慢查询日志，或者看了也没当回事。
索引这事儿，说起来简单，做起来全是坑。很多人觉得建索引就是给 WHERE 条件里的字段加个索引就完事了，但现实远比这复杂。比如联合索引，字段顺序搞反了，索引就废了一半。再比如覆盖索引，明明可以只查索引就拿到数据，却非要回表查一遍。还有最坑的一种情况：索引建了，但 SQL 写法导致索引用不上。我见过一个开发写的查询，WHERE userid + 1 = 100，这导致 MySQL 无法使用 userid 上的索引，因为索引是基于原值的，做了运算就失效了。改写成 WHERE userid = 99，性能直接提升几十倍。这种问题，说到底是基本功的问题，但偏偏很多人就是不长记性。
连接池也是个容易翻车的地方。很多团队上线前把连接池配得特别大，想着“多配点总没错”，结果反而出问题。数据库能同时处理的连接数是有限的，连接池越大，竞争越激烈，上下文切换越频繁，性能反而下降。我见过一个极端案例，某团队把连接池最大连接数设成 500，结果数据库服务器 CPU 被打满，连正常查询都响应不了。后来我们调成 50，性能反而上来了。为什么？因为数据库处理请求的核心是 CPU 和内存，不是连接数。连接数多了，每个连接分到的资源就少了，线程切换的开销却大了。这就像高速公路，车道再多，收费站只有几个，车全堵在收费站前面，效率反而低。
锁和死锁的问题，往往是并发场景下的噩梦。有一次我帮一个金融客户排查问题，他们的接口经常超时。我一看日志，发现大量死锁回滚的记录。场景是：两个事务同时操作同一张表，一个先更新 A 记录再更新 B 记录，另一个先更新 B 记录再更新 A 记录，结果互相等对方释放锁，死锁了。MySQL 虽然会自动检测死锁并回滚其中一个事务，但回滚本身有开销，而且业务层如果没处理重试逻辑，就会报错。解决方案说起来很简单：统一更新顺序，或者把事务粒度拆小。但很多开发写代码时根本没考虑锁的问题，上线前压测也没模拟高并发死锁场景，等到上线才发现。
硬件和配置层面的问题，同样不能忽视。我见过一个案例，某公司的数据库服务器仍在使用机械硬盘，SSD 都没上。结果每天凌晨跑报表时，IO 等待时间超过 50%，整个系统响应都变慢。后来换成 NVMe SSD，性能直接翻倍。还有内存配置，很多人觉得内存越大越好，但 MySQL 的 InnoDB 缓冲池、排序缓冲区、临时表大小等参数如果没调好，内存再多也白搭。比如 sortbuffersize，默认 256KB，如果经常做排序操作，这个值太小会导致频繁生成磁盘临时表，性能急剧下降；但调太大也不行，因为每个连接都会分配这个缓冲区，连接数多了，内存瞬间被吃光。所以数据库调优，从来不是“越大越好”或“越小越好”，而是“刚刚好”。
我想说，数据库性能问题本质上是一个“成本与收益”的博弈。加索引、加缓存、加机器都能提升性能，但都有成本。索引多了影响写入性能，缓存多了增加维护复杂度，机器多了烧钱。真正考验技术水平的，不是你会不会加索引，而是能否在不增加太多成本的前提下，把性能优化到业务能接受的程度。我见过太多团队，一遇到性能问题就想着加机器、换硬件，结果问题没解决，成本却翻了一番。真正的高手会先看慢查询日志，再看索引设计，再看 SQL 写法，才考虑加机器。因为很多时候，改一行代码或加一个索引就能解决问题，根本不需要花钱。
