MySQL性能优化实战：11年运维人从慢查到毫秒响应

　　2025年4月那会儿，我接了个急活——甲方说他们的订单查询从秒级掉到分钟级，销售在客户现场都快被骂哭了。我原以为就是索引没建好，结果登录服务器一看，慢查询日志里全是全表扫描，最离谱的一条SQL扫了八千万行，手机屏幕都快装不下日志了。办公室空调太冷，我裹着外套蹲在工位上，盯着EXPLAIN的输出，突然想起十年前带我的师傅说过的话：“优化SQL就像修水管，别光盯着漏水的地方，得看整个管网。”

　　甲方那边催得急，销售每隔半小时就在群里发张截图——客户在会议室拍桌子的照片，配文“再不解决要赔违约金了”。我翻出2018年写的优化手册，发现里面提到的“覆盖索引”和“MRR优化”现在居然还管用。但有个问题卡了我三天：某个JOIN查询明明加了索引，可执行计划还是走全表扫描。我查了MySQL的官方文档，又对比了不同版本的优化器行为，最后发现是统计信息过期——执行ANALYZE TABLE后，响应时间直接从两分钟掉到二十毫秒，销售在群里发了个“牛”的表情包，结果被甲方技术总监怼了句“早干嘛去了”。

　　其实最让我头疼的不是技术问题，是沟通。甲方坚持要“彻底解决”，可他们数据库里存了二十年的历史数据，有些表连主键都没有。我跟技术总监吵了一架，他说“你们运维不就是改改配置吗”，我直接把慢查询日志甩他脸上：“您看看这SQL，写的人怕是连EXPLAIN都没跑过。”后来我妥协了——给高频查询的表加历史分区，冷数据归档到单独的库，热数据用覆盖索引。折腾了大半个月，核心查询从分钟级掉到毫秒级，甲方终于松口说“暂时够用了”。

　　那天晚上我加班到十点，窗外天都黑了，手机快没电了还在回消息。突然想到个反常识的结论：现在很多人说“MySQL不行了，得换TiDB”，可我这十一年见过太多案例——90%的性能问题，根本不是数据库本身的锅。就像上个月帮个电商客户优化，他们花了五十万买分布式数据库，结果发现是应用层没做连接池，导致数据库连接数爆了。我原以为分布式能解决一切，结果发现，连最基本的“避免SELECT ”都没做到。

　　跟老板汇报的时候，他问我“优化的核心是什么”，我脱口而出：“优胜劣汰。” 他愣了下，我接着说：“不是淘汰MySQL，是淘汰那些不会用MySQL的人。” 比如那个扫八千万行的SQL，写它的人可能连“索引下推”都没听过；还有那个走全表扫描的JOIN，写它的人可能觉得“多等两分钟没关系”。现在很多团队招运维，要求会K8s、会Prometheus，可连最基本的SQL优化都不会——这就像让厨师去开飞机，菜都炒不熟，飞再高有什么用？

文章配图，仅供参考

　　现在甲方又提了新需求——要把历史查询的响应时间从秒级提到毫秒级。我翻了翻监控，发现他们有个表有一百多个字段，其中三十个是TEXT类型。我跟销售说：“这活得加钱，得先做字段拆分和垂直分区。” 销售叹了口气：“他们说预算有限。” 我盯着屏幕上的慢查询日志，突然有点心疼那些写烂SQL的人——他们可能不知道，自己随手写的一行代码，会让运维熬多少个通宵。

　　下一步我打算做个实验：把十年前写的优化脚本拿出来，跑在最新的MySQL 8.0上，看看哪些技巧还管用，哪些已经被淘汰了。其实我也没招——优化这事儿，没有一劳永逸的解法，只有不断踩坑、不断总结。就像我师傅说的：“运维这行，活到老学到老，不然迟早被淘汰。”

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!