MySQL优化技巧提升查询性能实战

做后端开发这几年，跟MySQL打交道算是家常便饭了。刚开始那会儿，写个查询能用就行，压根没想过性能这回事。直到后来线上系统被慢查询拖垮，用户一顿吐槽，才老老实实回头研究MySQL优化。今天就把我实际踩坑总结出来的MySQL优化技巧分享给大伙儿，都是实实在在能用的东西，不是那种光说不练的虚招子。

先学会看慢查询日志，别瞎猜

很多朋友一遇到MySQL查询慢，第一反应就是加索引，其实这是不对的。我刚开始也这样，结果加了索引反而更慢，后来才明白得先找到问题在哪。开启慢查询日志是最基本的操作，在my.cnf里设置slow_query_log=1，long_query_time设成1秒，跑个一天半天的再去看日志，哪些SQL语句是拖后腿的，一目了然。另外performance_schema和sys库也很有用，不过对新手来说，先把慢查询日志玩明白就够用了。记住，优化MySQL第一步永远是定位问题，而不是瞎改。

索引设计有讲究，不是越多越好

索引这块儿坑最深。我见过有人给表里每个字段都加了索引，结果写入慢得要命，磁盘占用也翻了好几倍。其实MySQL索引优化的核心原则就那几个：最左前缀原则、覆盖索引、区分度高的字段优先。比如你经常用where a=1 and b=2这种条件，那就建(a,b)联合索引，别分开建两个单列索引。还有，索引列别参与计算，比如where date(create_time)='2024-01-01'这种写法，索引直接失效，得改成create_time >= '2024-01-01' and create_time < '2024-01-02'。这些细节不注意，MySQL优化就是白忙活。

SQL语句改写，效果立竿见影

有时候表结构和索引都没问题，就是SQL写法太烂。最常见的就是select *，这玩意儿真害人，明明只需要两三个字段，非得把整行数据捞出来。改成只查需要的字段，IO开销立马降下来。还有避免在where子句里用函数或表达式，前面也提到了。另外，分页查询用limit offset大的时候会越来越慢，比如limit 100000,20，MySQL得先读10万行再扔掉，这时候可以改成先查主键id，再用id去关联，或者记住上一页最后一条的id，用where id > ? limit 20。这种MySQL优化技巧看起来不起眼，实际效果能快好几倍。

表结构设计也得用心

字段类型选不对，也会拖累MySQL性能。比如存储状态值，用tinyint就好，别用int；存IP地址，用int unsigned或者varchar都行，别用char(15)那种浪费空间。还有字段尽量设为NOT NULL，因为NULL值在索引里处理起来更麻烦，查询时也容易出幺蛾子。如果是超大表，考虑一下分区表或者分库分表，不过这个复杂度高，一般数据量没到千万级别别轻易碰。我见过一哥们儿，表里才几十万条数据就搞分表，结果代码改得乱七八糟，查询还得跨表union，纯属自找麻烦。

配置参数调优，锦上添花

如果SQL和索引都优化得差不多了，还是觉得慢，那可以看看MySQL的配置参数。innodb_buffer_pool_size这个最关键，一般设置为物理内存的60%-70%。还有query_cache_type，在MySQL 5.7及之前版本可以开启查询缓存，但8.0已经移除了这功能，所以如果你用的是8.0，就别惦记这个了。另外，max_connections连接数也别设太大，不然线程切换开销也够喝一壶的。这些参数得根据你服务器的实际情况慢慢调，别照搬网上的教程，每台机器的配置和业务都不一样。

日常巡检习惯很重要

最后唠叨一句，MySQL优化不是一锤子买卖，得养成习惯。每周抽点时间看看慢查询日志有没有新增，用explain分析一下执行计划，看看索引命中情况。explain输出里的type列，如果是ALL或者index，说明全表扫了，得想办法优化成range或ref。还有rows列，估算扫描的行数，跟实际返回行数差距太大就得注意了。把这些MySQL优化技巧用起来，形成一套自己的巡检流程，线上出问题的概率会小很多。

好了，这次就分享到这儿。上面讲的都是我在实际项目里验证过的MySQL优化经验，希望能给正在被慢查询折磨的朋友们一点帮助。如果你也有什么独门优化技巧，欢迎在评论区交流。