你打开监控面板，CPU飙到90%，慢查询日志刷了整整三页，数据库连接池被占满，用户那边已经开始骂娘。这种场景，做后端的人多少都经历过。数据库一卡，整个系统就像踩了刹车，谁调谁头大。但说句实在话，大部分性能问题根本轮不到上什么高端方案，就是一些基础动作没做到位。今天这篇东西，咱们就把调优这件事从头捋一遍，从你第一步该看什么，到后面怎么动手，每一步都讲明白。
第一步永远是定位瓶颈，别上来就改配置。很多人一遇到数据库慢，第一反应就是加内存、换SSD、调innodbbufferpoolsize，结果钱花了不少，问题还在那儿杵着。真正该做的，是先搞清楚慢在哪。慢查询日志开着没有？没开的话，set global slowquerylog=ON，longquerytime设成1秒，跑个半天看看。另外performanceschema和sys库别浪费，用sys.digest统计一下哪些SQL模板消耗最大，一抓一个准。还有个容易被忽略的地方，是锁等待。数据库CPU不高、IO也不忙，但请求就是快不起来，十有八九是行锁或者间隙锁在打架，查一下informationschema.innodbtrx，看看有没有长时间挂着的事务，多半是代码里事务没提交，或者事务里混了RPC调用。
瓶颈定位完了，索引优化是性价比最高的一步。说实话，大多数慢查询的根子，就是索引没建对。你建了索引但没走，或者建了三个单列索引但没建联合索引，又或者对索引列做了函数运算，导致索引直接失效——这些坑我见得太多。有个很实用的检查方法，explain你的核心查询，看type列。如果是ALL，说明全表扫描，得赶紧加索引；如果是ref或者range，说明索引用上了，但还有优化空间；要是eqref，那就比较理想了。还有一点，覆盖索引这个概念很多人不太当回事，但有时候你明明建了索引，查询还是慢，就是因为select了多余的字段，导致需要回表。把常用的查询字段都塞进索引里，让索引覆盖住你的查询，性能提升往往立竿见影。
索引建好了，接下来得检查SQL本身写得好不好。同样一个业务需求，写法不同，性能天差地别。比如select *和只select需要的字段，看起来差别不大，但在大表上，IO开销差好几倍。再比如or条件，有时候用union all拆开反而能走索引，有时候or两边都有索引，MySQL优化器也会犯迷糊。还有子查询，很多情况下改成join效率更高，但要注意，join的驱动表选择也很关键，小表驱动大表，这个原则别忘。另外，order by和group by要尽量走索引，避免filesort和temporary table，explain里面看到Using filesort或者Using temporary，基本就是该优化SQL的明确信号了。
说完SQL，咱们聊聊表结构层面的事情。字符集和排序规则统一，这个很多人不在意，但join的时候如果两边字符集不同，索引直接废掉。字段类型也别乱用，能用int就别用varchar存数字，能用datetime就别用字符串存时间。还有，大字段尽量拆出去，比如text、blob这种，单独放一张表，主表只留主键和外键引用，查询的时候大字段不参与扫描，速度能快不少。分表分库这个事儿，不要一上来就做，那是最后的手段。先看看你的数据量是不是真的大到单表扛不住了，一般单表超过千万行，或者单表超过10GB，这时候再考虑分库分表。而且分表策略要想清楚，按时间分还是按ID哈希分，得结合业务查询模式来定，不然分完表查询还是慢，反而更麻烦。
硬件和配置层面的调整，放在最后说，不是说不重要，而是它通常是锦上添花，不是雪中送炭。innodbbufferpoolsize设成物理内存的70%左右，这是最常见的一个调优项。但你要是表数据本身只有2GB，buffer pool设个128MB也够用了，设大了反而浪费内存。连接数也别盲目调大，maxconnections设成2000，但每个连接都要占内存，CPU调度压力也跟着涨，可能连接是够了，系统整体更慢。iouring、ODIRECT这些参数，属于进阶玩法，一般业务用不上，但你如果做的是高并发写入型业务，这些参数确实能带来不小的提升。日志刷盘策略，innodbflushlogattrxcommit设成0或2，能明显减少磁盘IO等待，但代价是可能丢最近1秒的事务日志，这个取舍得你自己权衡。
缓存层往往是数据库调优里最容易被忽略的杠杆。你数据库再怎么调，物理IO的延迟在那儿摆着，MySQL走一次索引也要几毫秒，但Redis拿一个key只要不到一毫秒。热点数据能放缓存就别打数据库，比如用户信息、商品详情、配置项这些读多写少的数据，缓存命中率能做到90%以上，数据库的压力直接降一个量级。但缓存也有坑，缓存穿透、缓存击穿、缓存雪崩，这三个问题得提前想好方案。穿透用布隆过滤器挡一下，击穿用互斥锁或者逻辑过期，雪崩用随机过期时间错开。缓存跟数据库的一致性，也别追求什么强一致，业务上能接受短暂不一致，就尽量用延迟双删或者订阅binlog异步更新，别把系统搞复杂了。
说个很多团队都踩过的坑——调优不是一次性的活儿，你得建立持续监控的机制。今天调好了，明天业务量涨一倍，可能又出问题。慢查询日志定期看，performance_schema的指标每周扫一遍，连接数、活跃事务数、buffer pool命中率这些核心指标，用Prometheus加上Grafana画个看板，每天扫一眼。另外，每次上线新功能，特别是涉及SQL变更的，先跑一遍explain，确认走索引再发布。这个习惯养成了，数据库出问题的概率能降低一大半。
数据库调优这件事，说白了就是一层窗户纸，捅破了没那么神秘。从慢查询日志和监控指标入手定位瓶颈，接着优化索引和SQL写法，再调整表结构和配置参数，用缓存扛住热点流量——这一套组合拳打完，大多数系统的数据库性能都能有明显的飞跃。但你别指望一劳永逸，业务在变，数据在涨，调优是个持续迭代的过程。把上面这套方法内化成习惯，再遇到性能告警，你心里就有底了。
