MySQL性能优化实战：5年运维的慢查到毫秒突破

去年二月份，我接到一个紧急工单——某电商平台的订单查询接口响应时间飙到3.2秒，直接触发系统告警。这可不是普通的慢查询，而是涉及订单表、用户表、商品表三表关联的复合查询，表数据量均超千万级。更棘手的是，业务方要求必须在48小时内解决，否则大促期间可能引发连锁故障。我翻出监控日志，发现慢查询日志里有个SQL语句执行时间长达2.8秒，占用了90%的查询耗时，这就是突破口。

先查执行计划，EXPLAIN一看，好家伙，全表扫描！订单表的order_date字段明明有索引，但优化器偏偏选了最慢的路径。我试着在WHERE条件里加上FORCE INDEX(order_date)，结果执行时间从2.8秒直接掉到0.8秒——但业务方不接受强制索引，说可能影响其他查询逻辑。这时候，新技术派上用场了：我盯上了MySQL 8.0的直方图统计功能。通过ANALYZE TABLE收集字段分布，发现order_date字段的数据倾斜严重——80%的订单集中在最近3个月，而优化器默认按均匀分布计算成本，自然选错了索引。调整直方图桶数到20（默认是100，但千万级表选20更精准），重新生成统计信息后，优化器自动选择了正确的索引，查询时间稳定在0.3秒以内，连FORCE INDEX都不用写了。

但别以为这就结束了——我曾踩过一个坑。有次优化一个报表查询，表数据量5000万，原查询用LEFT JOIN关联5张表，执行时间15秒。我照搬直方图的思路，给所有关联字段都加了索引，结果执行时间反而涨到20秒！后来发现，问题出在JOIN顺序上：优化器先扫了最大的表，再关联小表，导致中间结果集爆炸。最后用STRAIGHT_JOIN强制指定小表驱动大表，配合覆盖索引，才把时间压到1.2秒。这告诉我，新技术不是银弹，得结合执行计划、数据分布、业务逻辑综合判断——直方图能解决索引选择问题，但解决不了JOIN顺序的“脑残”决策。

还有个细节别人很少提：索引碎片对慢查询的影响可能比想象中大。我遇到过一个案例，某表的索引碎片率高达40%（通过SHOW INDEX统计），同样的查询，碎片整理前要1.5秒，整理后直接降到0.2秒。碎片是怎么来的？频繁的DELETE+INSERT操作，导致索引页不连续，扫描时需要多次IO。解决方法很简单：对大表定期执行OPTIMIZE TABLE，或者用pt-online-schema-change在线整理（生产环境更安全）。不过得注意，OPTIMIZE TABLE会锁表，千万级表建议在低峰期操作——我曾因为没选对时间，被业务方投诉了三次。

文章配图，仅供参考

下一步我打算研究MySQL的Performance Schema——听说它能实时监控锁等待、IO延迟这些底层指标，或许能帮我发现更多隐藏的性能瓶颈。不过说实话，慢查询优化没有终点，每次解决一个，业务方又会提出更高的要求——比如现在他们要求所有接口响应时间不超过200毫秒，这可比从秒级到毫级难多了。但这就是运维的乐趣，不是吗？

（编辑：站长网）

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