那天下班前，运维兄弟火急火燎地跑过来：“生产库又卡死了，一个简单的查询跑了快两分钟，老板在群里点名了。”
我放下手里的泡面，打开慢查询日志一看，好家伙——一个本该毫秒级返回的列表页，硬生生把全表几百万条数据扫了个遍。这问题太典型了：索引没建对，缓存没配好，SQL写得随心所欲。其实数据库调优这事儿说穿了就六个字——“让数据少跑路”。今天咱们就掰开揉碎了聊聊，从索引到缓存，六种实战方式怎么把数据库性能从“爬”变成“飞”。
先说说最基础的索引优化。很多人觉得索引就是建个B+树完事儿，但索引建不对，反而拖后腿。我见过最离谱的案例，一张表上挂了十几个单列索引，结果查询时MySQL一个都用不上，因为压根没覆盖到查询条件。正确的做法是“联合索引优先”，比如经常按“用户ID+订单时间”查，就建一个(userid, ordertime)的联合索引，让查询条件左边的字段尽量匹配索引前缀。还有个小技巧：索引列上别做函数操作，比如WHERE DATE(createtime) = '2024-01-01'，这会让索引失效，改成createtime >= '2024-01-01' AND createtime < '2024-01-02'就能走索引。索引不是越多越好，关键看执行计划——用EXPLAIN扫一眼，看到“type”是“ALL”或者“rows”特别大，就说明索引没吃准。
索引搞定后，SQL语句本身的优化更不能忽视。我见过一个工程师写了个嵌套子查询，里面套了三层，跑了一个小时没出结果。其实改成JOIN，十秒完事。核心原则就是：能用JOIN就别用子查询，能用EXISTS就别用IN，能用LIMIT就别全量拉。还有那些批量操作，别一条一条INSERT，用INSERT INTO … VALUES (…), (…)一次插一千条，效率翻十倍。另外，排序和分组也是性能杀手。ORDER BY要配合索引，如果排序字段不在索引里，MySQL就得用文件排序，数据一多就炸。GROUP BY也一样，尽量让分组字段走索引，或者用临时表先预处理。SQL写得好不好，直接决定数据库是“干活”还是“受刑”。
说完了查询优化，再聊聊表结构设计。很多人建表时图省事，字段类型全用VARCHAR(255)，甚至把大文本塞到同一个表里。结果表一膨胀，单行数据量大得吓人，索引也撑不住。正确的做法是：字段类型要精准，能INT就别VARCHAR，能SMALLINT就别BIGINT。比如状态字段用TINYINT，省空间还快。大字段（TEXT、BLOB）要单独拆出去，用主键关联，避免拖慢主表查询。还有分区表，数据量上亿时，按日期或按用户ID分区，查询只扫一个分区，比全表扫描快一个数量级。当然，分区不是万能药，分得太细反而管理麻烦，通常按季度或按月分区就够用。表结构设计就像盖楼打地基，地基稳了，上层优化才有意义。
索引、SQL、表结构都调优了，但高并发下还是会卡，这时候就得靠缓存来扛。缓存分两层：应用层缓存和数据库内置缓存。应用层用Redis或Memcached，把热点数据（比如用户信息、配置数据）直接放内存里，查询时先查缓存，没命中再查数据库。我给一个电商项目做过优化，商品详情页的访问量一天几千万，把商品基本信息放Redis后，数据库压力直接降了80%。数据库内置缓存也不容忽视，MySQL的InnoDB buffer pool大小直接影响性能，默认才128MB，线上环境至少配到物理内存的70%。还有查询缓存，MySQL 8.0虽然废弃了，但可以用第三方工具或业务层缓存来替代。缓存的灵魂就一句话：“把高频访问的数据留在内存里，别让数据库去磁盘上翻。”
硬件和配置层面的优化，很多人觉得是“傻大粗”，但其实性价比很高。先看配置文件，MySQL的innodbbufferpoolsize、innodblogfilesize、maxconnections这几个参数，默认值简直是给玩具服务器用的。拿innodblogfile_size来说，默认48MB，如果业务写入频繁，很快写满导致频繁刷盘，改成1GB立马见效。再看硬件，SSD是标配，机械硬盘在随机IO场景下就是瓶颈。还有内存，64GB起步，128GB不嫌多，因为InnoDB buffer pool越大，磁盘IO越少。网络方面，应用和数据库尽量同机房部署，延迟能控制在1ms以内。硬件配置就像运动员的体能，底子不行，技术再好也跑不快。
说说监控与持续优化。调优不是一锤子买卖，得靠数据说话。我习惯用pt-query-digest分析慢查询日志，把执行频率高、耗时长的SQL揪出来，每周优化一次。还有Prometheus+Grafana监控数据库的QPS、TPS、连接数、锁等待等指标，一旦发现异常波动，立刻排查。比如突然出现大量“Waiting for table metadata lock”，说明有DDL操作阻塞了查询，得赶紧处理。另外，定期用OPTIMIZE TABLE整理碎片，用ANALYZE TABLE更新统计信息，让优化器做出更好选择。监控就像数据库的体检报告，不体检就不知道哪里出了问题。
回到开头那个案例。我花了半小时，把那个慢查询从“扫全表”改成“走索引”，再给热点数据加了Redis缓存，查询时间从两分钟降到20毫秒。运维兄弟激动得差点请我吃火锅。
数据库调优这事儿，说白了就是“让数据少跑路，让查询走捷径”。从索引到SQL，从表结构到缓存，再到硬件和监控，六种方式环环相扣。别指望一劳永逸，也别迷信某个“银弹”。真正的调优高手，都是先理解业务场景，再对症下药。下次你的数据库卡了，别急着重启，按这六个步骤走一遍，大概率能解决问题。毕竟，数据库不是用来烧CPU的，它是用来服务业务的——让它跑得快，才是正经事。
