写这篇文章的时候，我脑子里一直有个画面：凌晨三点，服务器报警，数据库CPU飙到100%，页面打不开，老板电话追过来。这种场景，做过后端的人都不陌生。MySQL优化这事，说难不难，说简单也不简单，关键是得找对方法。今天咱们就聊聊我这些年踩过的坑和总结出来的五招。
先说索引。很多人觉得建索引就是加个字段的事，其实真不是这样。我见过最典型的案例是，一张表几百万数据，查询用了全表扫描，一次查询动不动十几秒。后来加了联合索引，把查询条件里的字段按顺序放进去，查询直接降到几十毫秒。这里有个坑：索引不是越多越好，索引也会占用磁盘空间，还会拖慢写入速度。而且，联合索引最左前缀原则必须搞清楚，不然建了等于白建。比如你建了(a,b,c)的联合索引，但查询条件只用到b和c，这个索引就用不上。经验是，先分析慢查询日志，找到最频繁的查询模式，再针对性地建索引。
说到慢查询，就得提explain这个工具。我每次优化之前，第一件事就是跑explain。它能告诉你MySQL是怎么执行这条查询的，用了哪些索引，扫描了多少行。有次我查一个订单表，用explain一看，发现明明有索引，但type列显示的是ALL，全表扫描。原因很简单，查询条件里用了函数，比如where DATE(createtime) = '2024-01-01'，这就导致索引失效。改成范围查询，where createtime >= '2024-01-01' and createtime < '2024-01-02'，立马就用了索引。explain的type列从ALL到range到ref到const，性能依次提升，这是每个DBA都要背下来的东西。
表结构设计这块，很多人容易忽略。我接手过一个系统，一张表有80多个字段，其中很多是varchar(255)甚至text类型。这种表别说查询了，连表结构都看着头疼。优化的思路是：能拆就拆。把不常用的大字段单独拆成一张表，用主键关联。还有，字段类型要选对。比如状态字段，别用varchar存"已支付"这种字符串，用tinyint存0和1，效率能差一个数量级。另外，时间字段尽量用datetime或者timestamp，别用varchar存，不然排序和范围查询都会很痛苦。
SQL语句的写法，往往是性能瓶颈的重灾区。我见过最夸张的，有人写了个嵌套子查询，里面还有limit，结果外层循环一次就要执行一次子查询，数据量一大直接炸了。这种场景，用join改写一下，效率能提升几百倍。还有个常见问题：select 。很多人习惯写select ，但如果你只需要两三个字段，这么做会让MySQL去读整个数据页，IO开销大。只取需要的字段，能少读很多数据。另外，union all比union好，因为union会做去重操作，多一次排序。批量操作也比逐条操作快，insert into values (a,b),(c,d)这种方式，比循环insert快得多。
缓存策略，这是很多人在MySQL优化里容易忽略的一环。实际上，MySQL自己的查询缓存，在8.0版本之后已经废弃了，因为在高并发下反而会变成瓶颈。但这不代表不用缓存。常见的做法是，在应用层引入Redis或者Memcached，把热点数据缓存起来。比如商品详情页，每次请求都查数据库，压力太大了。第一次查完放Redis里，设置个过期时间，后面的请求直接读缓存，数据库压力瞬间降下来。但缓存也有坑，缓存雪崩、缓存穿透、缓存击穿，每种都有对应的解决方案。最简单的做法是，热点数据设置不同的过期时间，加上随机因子，防止同时过期。
说说硬件和配置。很多人觉得加内存就能解决一切，其实不然。MySQL的配置参数里，innodbbufferpoolsize是最关键的一个，它决定了InnoDB能缓存多少数据和索引。一般建议设为物理内存的70%左右，但也要留一些给操作系统和其他进程。还有个参数是querycachesize，这个在8.0里已经废弃了，别再用。磁盘方面，SSD比HDD快得多，尤其是随机读写场景。如果条件允许，用NVMe固态，IO延迟能降到微秒级。但硬件优化是锦上添花，不是雪中送炭。如果你的SQL写得稀烂，再好的硬件也扛不住。这五招，从索引到SQL，从表结构到缓存，再到硬件，层层递进。每解决一层问题，数据库性能就能上一个台阶。
