聊到 MySQL 数据库优化，很多人第一反应就是加索引、调参数，甚至直接扔给 DBA 一句“你帮我看看”。但干这行久了会发现，真正能扛住千万级流量的系统，往往不是靠某个“神操作”搞定的，而是从业务逻辑到数据模型、从查询习惯到硬件配置，一层层抠出来的。今天咱们就聊聊那些平时可能忽略，却特别关键的优化细节。
先说个最扎心的事儿：很多慢查询其实不是 SQL 写得差，而是表结构本身设计不当。比如你有个用户表，里面塞了二十多个字段，昵称、头像、手机号、地址、积分、登录 IP……这些字段全堆在一个大表里。平时查个登录记录，还要把整行数据都拉出来，IO 开销能不高吗？这时就该考虑垂直拆分，把频繁查询的字段单独拎出来，比如用户核心信息一张表，扩展属性另一张表，甚至把日志类字段直接扔到归档表。别小看这一步，我见过一个电商后台，把商品描述和图片 URL 从主表拆分后，查询响应时间直接从 2 秒降到 200 毫秒。
索引这事儿，说起来简单，用起来全是坑。很多人觉得“索引越多查得越快”，结果一个表挂了四五个索引，插入数据时慢得像蜗牛。实际上，索引不是越多越好，而是越精准越好。比如你查询订单表，常按“用户 ID + 下单时间”筛选，那建一个联合索引 (userid, ordertime) 就比分别建两个单列索引高效得多，因为 MySQL 能一次索引扫描找到目标行，不用回表两次。还有一种常见错误：在性别、状态这种区分度极低的字段上建索引，结果扫描了 50% 的数据才找到目标，还不如全表扫描快。记住，索引的价值在于缩小范围，区分度低于 20% 的字段，建了也是白建。
说完索引，聊聊 SQL 写法。很多开发习惯写“SELECT ”，觉得省事，但这其实是性能杀手。想象一下，一张表有 20 个字段，你只需要其中 3 个，MySQL 仍要把整行数据从磁盘读到内存，再通过网络传给你，白白浪费了 IO 和带宽。更麻烦的是，这种写法还会让索引失效——如果查询的字段不在索引里，MySQL 就得回表查，性能直接打折。正确的做法是只选需要的字段，比如“SELECT id, name, status FROM users WHERE …”。别小看这个改动，我优化过一个统计报表，把“SELECT ”改成精准字段后，查询耗时从 8 秒降到 0.5 秒，因为减少了大量不必要的磁盘读取。
再往下挖，就是执行计划（EXPLAIN）的解读。很多人跑完 EXPLAIN，看到 “type: ref” 就觉得万事大吉，但其实 “rows” 那一列才是关键。比如你查询一个 100 万行的表，EXPLAIN 显示 rows=50 万，那就算用了索引，实际扫描的行数仍然太多。这时该想想：是不是索引没覆盖全部条件？是不是查询条件太宽泛？比如 “WHERE status IN (1,2,3,4)” 虽然用了索引，但扫描的行数可能接近全表。更好的做法是缩小 IN 列表的范围，或者用分区表把数据按状态拆开。另外，注意 “extra” 列里的 “Using filesort” 和 “Using temporary”，这通常意味着查询需要额外排序或创建临时表，多半是索引没有覆盖排序字段导致的。
缓存是 MySQL 优化的另一大杀器，但很多人用错了。比如在业务代码里手动给每个查询加 Redis 缓存，结果热点数据没命中，冷数据却占满了内存。更合理的做法是：先分析业务访问模式，把高频查询（比如首页推荐、用户基本信息）的缓存时间设长一点，低频查询（比如历史订单、日志）直接绕过去。MySQL 自身也有查询缓存，但 MySQL 8.0 已经彻底移除这个功能，因为在高并发场景下，查询缓存的锁竞争反而拖垮性能。所以现在更推荐用外部缓存层，如 Redis 或 Memcached，配合业务逻辑做主动失效，而不是依赖 MySQL 自带的缓存。
硬件和数据量达到一定规模时，分库分表就不可避免。但很多人一上来就搞分库分表，结果业务复杂十倍，维护成本暴涨。实际上，很多场景用分区表就能解决。比如订单表按时间分区：每个月一个分区，查询三个月内的订单时，MySQL 自动只扫描对应分区，速度飞快。如果分区仍不够，再考虑水平拆分。比如按用户 ID 哈希分到 4 个库，每个库再按时间分表。但要注意，分库分表会带来跨库查询、事务一致性、分布式 ID 生成等问题，并非万能。我见过一个系统，每天新增 100 万条日志，用分区表撑了两年，直到数据量突破 50 亿才不得不分库。所以，先做分区，再考虑分库，别一上来就上重武器。
想说，MySQL 优化不是一锤子买卖，而是持续迭代的过程。你优化了索引，可能几个月后业务变了，查询模式也变了，索引就失效了。你调整了缓存策略，可能上线一个新功能，热点数据就转移了。所以，定期用慢查询日志、Performance Schema 等工具做监控，发现瓶颈就动手改。别指望一次优化管一辈子，也别迷信所谓“最优配置”。真正懂优化的人都知道没有银弹，只有不断对业务和数据量做适配。说白了，MySQL 就像一辆车，开久了就得保养，换机油、查轮胎、调刹车，才能跑得又快又稳。
