我刚接手一个电商平台的时候，数据库查询慢得像蜗牛爬。用户点个“我的订单”，页面得转好几圈才出来。老板站在我身后，语气很平静，但问题很尖锐：“这网站是不是该回炉重造了？”我盯着慢查询日志，发现很多SQL语句都在全表扫描，有些表数据量已经上千万了，索引却少得可怜。MySQL优化这件事，说穿了就是跟数据较劲——你让它少干点活，它就跑得快。
第一个技巧，索引不是越多越好，而是越精准越好。很多人一听说查询慢就疯狂加索引，结果索引建了一大堆，写入变慢了，查询也没快多少。正确的做法是先看慢查询日志，找到那些执行时间长的SQL，然后用EXPLAIN分析执行计划。比如你查用户表，WHERE条件里经常用email字段，那就在email上建索引。但如果你查的是性别字段，男女比例差不多各一半，建索引反而没用——数据库会认为还不如全表扫描来得快。我见过最典型的错误是，有人给每个字段都加了索引，结果一张表有十几个索引，查询优化器都不知道该用哪个，性能反而下降了。
第二个技巧，合理利用覆盖索引。这个听起来有点专业，但理解起来很简单：如果你的查询只需要从索引里就能拿到所有数据，就不用回表去查整行记录。比如你查用户ID和姓名，而这两个字段刚好都在联合索引里，那MySQL直接走索引就能返回结果，比回表快好几倍。我优化过一个订单查询，原本要查十几个字段，改成只查索引里有的字段后，查询时间从800毫秒降到了50毫秒。当然，这要求你在设计索引时，把常用查询的字段都包含进去。
第三个技巧，分页查询别再用OFFSET了。很多人在做分页时，习惯写LIMIT 100, 20这种语句。你想想，MySQL为了拿到这20条记录，得先扫描10万行数据，然后扔掉前99980行，这得多浪费。更好的做法是用游标分页，也就是记录上一页一条记录的ID，然后查询条件写成WHERE id > 上一页最大ID LIMIT 20。这样MySQL直接走索引定位，不需要扫描无用的行。我改过一个后台管理系统，数据量500万，分页查询从3秒优化到了0.1秒，用户再也不用泡杯茶等着了。
第四个技巧，避免在索引列上做函数操作。这个坑很多人踩过。比如你查用户注册时间，写成了WHERE DATE(createtime) = '2024-01-01'，这时候MySQL不会用索引，因为它在计算函数之前不知道结果是什么。正确的写法是WHERE createtime >= '2024-01-01' AND createtime < '2024-01-02'，这样就能走索引了。类似的还有把字符串字段用数字比较，比如WHERE phone = 138000，MySQL会隐式转换，同样不走索引。这些小细节，看起来不起眼，但累积起来就是几十倍的性能差距。
第五个技巧，用好MySQL的查询缓存，但别迷信它。MySQL 8.0之前有查询缓存功能，但实际效果很鸡肋——只要表有更新，缓存就全失效了。所以我更推荐用应用层缓存，比如Redis。常见的做法是把热门数据缓存起来，比如首页推荐商品、用户基本信息。设置缓存过期时间，比如5分钟，这样既保证数据新鲜度，又大幅减少数据库压力。我做过一个活动页面，并发量瞬间飙升到每秒5000次请求，数据库直接被压垮。加了Redis缓存后，大部分请求直接命中缓存，数据库的负载降到了原来的十分之一。
第六个技巧，表设计上要舍得做垂直拆分。很多新手喜欢把所有字段塞到一张表里，结果一张表有几十个字段，查询时加载大量无用数据。正确的做法是把经常一起查询的字段放在一张表里，不常用的字段拆分到另一张表。比如用户表，可以把登录名、密码、邮箱这些常用字段放主表，而用户的收货地址、个人简介这些不常用的字段放扩展表。这样查询登录验证时，只需要加载几十个字节的数据，而不是整条记录的几千个字节。内存占用少了，查询自然就快了。
第七个技巧，合理使用读写分离。很多业务场景是读多写少，比如电商平台，用户浏览商品是写操作的几十倍。这时候可以把主库只用来处理写操作，从库专门负责读操作。MySQL的主从复制机制已经非常成熟，延迟通常可以控制在毫秒级别。我优化过一个论坛系统，主库压力太大导致发帖都卡。做了读写分离后，主库专注于处理发帖、回帖这些写操作，从库扛住了90%的查询请求，整个系统丝滑了不少。当然，要注意从库的延迟问题，如果业务对数据一致性要求极高，比如支付系统，就不适合用从库读。
第八个技巧，临时表用不好，性能直接崩。很多人习惯在存储过程或者复杂查询里创建临时表，但临时表默认是在磁盘上的，频繁创建和销毁会触发大量I/O操作。如果能用内存表，比如MEMORY存储引擎，性能会好很多。但内存表有个限制，数据量不能太大，否则会占用太多内存。还有一个更实用的做法是，尽量用子查询或者JOIN替代临时表。比如你要统计每个类别的商品数量，直接写GROUP BY比创建临时表再查要高效得多。我见过最夸张的例子，有人为了处理一个报表，创建了5个临时表，跑了10分钟还没出结果。改成单条JOIN查询后，20秒就搞定了。
第九个技巧，定期做数据归档和清理。很多系统运行久了，历史数据越积越多，但业务上其实很少用到。比如订单表，用户只关心最近三个月的订单，三年前的数据完全可以归档到历史表或者冷存储里。我优化过一个财务系统，主表有2亿条记录，每次查询都慢得要死。把三年前的数据迁移到归档表后，主表只剩5000万条，查询效率提升了10倍。而且归档数据还可以用分区表来管理，按月份分区，查询时只需要扫描相关分区，不需要全表扫描。
第十个技巧，监控和调优要持续迭代。MySQL优化不是一劳永逸的事，业务在变，数据量在涨，查询模式也在变。我的做法是，部署一套慢查询监控系统，每天自动分析执行时间超过1秒的SQL，然后逐个优化。同时定期检查索引使用情况，删除那些长期没被用到的索引。还有一个容易被忽略的点，是数据库的配置参数。比如innodbbufferpoolsize，这个参数决定了InnoDB存储引擎能使用多少内存来缓存数据和索引。默认值往往偏小，如果服务器内存有64G，可以设置到40G左右，性能提升非常明显。但别盲目改参数，每个参数都要结合监控数据来调整，不然可能适得其反。
回到开头那个电商平台，我用上面这些技巧，把数据库的平均查询时间从2.3秒降到了0.1秒。老板后来跟我说，用户反馈“网站变快了”。其实哪有什么魔法，不过是在每个细节上较真罢了。MySQL优化这件事，真正的价值不在于炫技，而在于让用户感受到“快”这个字有多重。你每省下来的那几百毫秒，都可能意味着多留住一个用户，多成交一笔订单。
