我干了十几年数据库运维，见过太多人把MySQL当黑盒用——表建好了，SQL写出来能跑就行，等到页面加载要好几秒、服务器CPU飙到100%的时候，才慌慌张张跑来问“怎么优化”。其实MySQL调优没那么玄乎，它就是一门“等价交换”的艺术：你用时间去换空间，用空间去换时间，用对索引去换查询速度。今天我就把这五个最实用的方法掰开揉碎讲给你听，全是实战里摔出来的经验。
先说索引使用。我见过最离谱的案例是，有人给一个几百万行的表建了十多个索引，每个字段都单独加索引，觉得“越多越好”。结果查询没快多少，写入反倒慢得离谱。索引的本质是“书的目录”，目录太厚了，翻目录本身就要花时间。真正有效的索引策略是：优先处理慢查询日志里频率最高的那几个SQL，针对它们的WHERE条件、JOIN字段、ORDER BY字段来建联合索引。比如你经常查“某个时间段的订单并按金额排序”，那就建一个(createtime, amount)的联合索引，顺序不能错——最常用的等值条件放左边，范围条件放右边。别想着一次建完，索引是动态调整的，跑一个月慢查询日志后再回头看，该删的删，该合并的合并。
再来说SQL语句本身。很多人觉得“数据库嘛，SQL能跑就行”，这是最大的误区。我亲眼见过一个报表查询，同样的业务逻辑，有人写嵌套子查询跑了三分钟，改成JOIN加临时表后只用了零点几秒。MySQL的查询优化器没你想的那么聪明，它经常犯傻。比如避免用SELECT ，你只需要三个字段就只查三个字段，减少数据传输量；避免在WHERE条件里对字段做函数运算，比如WHERE DATE(createtime) = '2024-01-01'，这会让索引失效，正确的写法是WHERE createtime >= '2024-01-01' AND createtime < '2024-01-02'；还有，尽量用EXISTS代替IN，尤其在子查询返回大量数据时，性能差距可能差几十倍。这些细节，改一个可能就省几台服务器。
表结构设计也是大坑。我接手过一个项目，订单表里有个字段存了几百个JSON格式的标签，每次查询都要用LIKE模糊匹配，那效率能高才怪。正确的做法是：按业务把字段拆分到关联表里，ID、标签名称、用户ID三列，加上联合索引，查起来快得飞起。另外，字段类型选择要抠细节——能用INT就别用VARCHAR，能用DATE就别用DATETIME，能用TINYINT就别用INT。比如状态字段就几个值，用TINYINT存0、1、2，比VARCHAR('pending')省几十倍空间。别小看这些，一张表几千万行，省下来的空间就是省下来的IO时间。
分区表是个好东西，但很多人用错了。分区不是让你把所有表都分区，它适合那种有明显时间维度的数据，比如日志表、历史订单表。按月份分区后，查上个月的数据就只扫描一个分区，而不是全表。但要注意，分区字段必须是查询条件里最常用的那个，而且分区数量别太多，几十个就够。我见过有人按天分区，一年下来三百多个分区，查询时MySQL要遍历所有分区元数据，反而变慢了。分区还有个隐藏福利：删除历史数据时，直接DROP分区比DELETE快一万倍，对线上业务几乎零影响。
缓存是MySQL性能的“外挂”。很多人以为加了Redis就万事大吉，但缓存策略不对，反而会雪崩。我的建议是：对读多写少、价值高、数据量不大的数据，比如用户基本信息、商品详情，用缓存非常划算。但要注意两点：缓存失效时间要设置随机值，防止大批量同时过期导致缓存雪崩；缓存更新要用“先更新数据库，再删除缓存”的方式，而不是先更新缓存。因为数据库和缓存之间永远存在时间差，这个策略能最大限度保证一致性。另外，MySQL自身的查询缓存，在8.0版本后已经废弃了，别再用那个鸡肋功能了。
配置参数是“核武器”，千万别一上来就调配置。很多人觉得“我服务器内存大，把innodbbufferpoolsize调到80%总没错”，但忽略了MySQL的内存分配是分多个缓冲区的，调太大反而会导致内存碎片。正确做法是：先跑一周的监控，看内存使用率、磁盘IO等待、慢查询日志，然后针对性调。比如你发现磁盘IO很高，那就调大innodblogfilesize减少日志写入频率；如果查询缓存命中率极低，那就把querycachetype设为0彻底关闭。配置调优像中医，望闻问切后才能开方子，别盲目跟网上的“标准配置”，你的业务场景和别人不一样。
讲个真实案例。前年帮一家电商公司做优化，他们双十一后订单表涨到一亿多行，每次查用户历史订单要三十多秒。我按上面五步走了一遍：先分析慢查询日志，发现80%的慢SQL都是查最近三个月订单；于是对订单表按月分区，只保留最近三个月在热分区；把查询SQL从SELECT 改成只查必要字段；给userid和createtime建联合索引；把用户最近订单缓存在Redis里，失效时间随机偏移。两周后，同样的查询从三十秒降到了零点几秒，服务器CPU使用率从80%降到20%。你看，MySQL优化就是这么回事——别想着一次搞个大新闻，而是把每个环节的“浪费”抠出来，积少成多，效率翻倍就是水到渠成的事。
