上周去一家创业公司做技术交流，他们的CTO拉着我吐槽：数据库查询越来越慢，用户打开页面要等三秒，老板已经在群里发火了。我看了眼他们的慢查询日志，一条SQL跑了8秒，索引压根没建对。帮他调完，查询时间从8秒降到0.3秒。他当场愣住，说早知道这么简单，何苦天天熬夜加服务器。
这事让我想起很多团队的通病——MySQL一慢就想着加机器、上缓存、换中间件，结果钱花了不少，问题还在那。其实绝大多数慢查询，都是因为没把SQL和索引这层基本功做扎实。今天就把我这些年总结的实战经验整理出来，从索引设计到SQL改写，再到参数调优，一步步带你让查询速度真正飙升。
先说索引这块。很多人建索引就是给WHERE条件字段随便加个普通索引，但实际效果往往大打折扣。比如有个订单表，用户经常按“用户ID+订单状态+创建时间”来查，你只在用户ID上建了索引，MySQL还得回表过滤订单状态和时间。正确的做法是建联合索引，把筛选最频繁的字段放前面。我遇到过最典型的案例：一个电商平台的订单查询页，原来查询要6秒，改成联合索引（用户ID，订单状态，创建时间）后，直接降到0.1秒。注意联合索引还有个最左前缀原则，字段顺序错了索引就废了。
索引设计完了，SQL写法也得跟上。很多开发习惯写SELECT ，觉得省事。但你要知道，MySQL从磁盘读数据是按页来的，一页16KB，你字段越少，一页能装的行数越多，查询时磁盘IO就越少。有个真实案例：某公司一个报表查询，SELECT 返回50个字段，实际只用5个，查询耗时2.3秒。改成只查需要的5个字段后，0.4秒搞定。另外WHERE条件里别用函数，比如WHERE DATE(createtime)=‘2023-01-01’，这会让索引失效。改成WHERE createtime>=‘2023-01-01’ AND createtime<‘2023-01-02’，立马走索引。
再来说说分页查询的坑。很多文章教你用LIMIT加OFFSET，但OFFSET越大性能越差。比如查第100万页的10条数据，MySQL会先扫描前100万行，再丢掉，只返回10行。这等于做了大量无用功。我建议用游标分页，记住上一页一条记录的ID，然后WHERE id>上一页最大ID LIMIT 10。改完之后，不管翻到第几页，查询时间都稳定在毫秒级。有个社交APP的Feed流就是这么改的，原来翻到第50页页面就卡死了，改完翻到1000页都秒开。
表结构设计这块也容易被忽略。最典型的就是字段类型选不对，比如状态值用VARCHAR存“正常”“异常”，其实用TINYINT存0和1就行，能省5倍空间。还有时间字段，很多人用VARCHAR存，查询时还得转格式，索引也用不上。直接用DATETIME或者TIMESTAMP，占用空间小，还能直接比较。另外，大字段比如TEXT、BLOB尽量拆到单独的表里，主表只存ID，需要时才去查。我见过一个内容管理系统，文章内容用TEXT存主表里，查询列表时全表扫描，改成分表后查询快了10倍。
参数调优也是硬功夫。很多公司MySQL装完就默认配置跑，innodbbufferpoolsize设成128MB，而服务器内存有64GB。这个参数决定了InnoDB能缓存多少数据和索引，设小了磁盘IO频繁，设大了浪费内存。建议设为服务器物理内存的70%左右，但别超过80%，免得操作系统内存不够。还有个参数querycachesize，在MySQL 8.0已经被废弃了，但很多人还在用5.7版本并且开着查询缓存。实际上查询缓存对写频繁的表反而有害，每次更新都要清缓存，建议直接关闭。另外，tmptablesize和maxheaptablesize设大点，能减少磁盘临时表的使用。
说说慢查询日志的用法。很多团队压根没开，或者开了但没人看。建议把slowquerylog打开，longquery_time设成1秒甚至0.5秒，然后定期分析。我习惯用pt-query-digest工具，能自动把慢查询按频率和总耗时排序，一眼就能看出哪些SQL最该优化。有个客户复盘时发现，一个慢查询占了数据库总负载的80%，优化完整个数据库压力降了一半。记住，性能优化不是一次性的活，要形成监控-分析-优化的闭环。
回到开头那个故事，那个CTO后来跟我说，优化完数据库后，服务器从8台减到3台，每年省了十几万。其实MySQL优化没那么玄乎，核心就是理解它的工作原理，然后对症下药。索引设计、SQL写法、表结构、参数调优，这四个环节做好了，查询速度飙升10倍不是梦。下次遇到慢查询，别急着加机器，先看看索引建对没，SQL能不能改写，说不定几分钟就能解决问题。
