MySQL性能优化实战：慢查询到毫秒响应全链路突破

半年前接手一个电商项目，用户反馈订单查询页面加载超3秒——这在我经手的项目里算严重事故了。翻看慢查询日志，发现一条SQL执行时间稳定在2.1秒，涉及3张表关联查询，其中订单表有280万条数据，商品表120万条，用户表80万条。当时团队里有人提议加索引，但测试环境加了3个复合索引后，执行时间反而涨到2.4秒——典型的"索引越多越慢"反面教材。

后来用EXPLAIN分析执行计划，发现MySQL走了全表扫描：订单表的status字段明明有索引，但查询条件里混用了status=1和status IN (1,2)两种写法——前者能用索引，后者会导致索引失效。更坑的是，商品表的name字段用了LIKE '%手机%'模糊查询，这直接让优化器放弃索引。改写成status IN (1)并去掉模糊查询后，执行时间降到0.8秒，但离毫秒级还差得远。

文章配图，仅供参考

但别以为这样就万事大吉了。有次把并行度设成8，结果服务器CPU飙到90%，查询反而超时——并行查询不是越多越好，得根据服务器核心数调参。还有个隐藏坑：并行查询对临时表无效。有次优化一个带GROUP BY的复杂查询，发现并行度设成4后，响应时间反而从0.3秒涨到0.5秒，排查半天才发现是中间结果存到了临时表，并行查询没生效。

最狠的优化是改写SQL逻辑。原查询要同时返回订单信息、商品名称和用户昵称，团队之前用3次子查询，我改成JOIN+临时表：先查订单主表，把订单ID存到临时表，再用临时表关联商品和用户表。这样虽然SQL变长了，但执行计划里没了"Using temporary; Using filesort"这两个致命标记，响应时间从0.23秒降到0.08秒——这才是真正的全链路突破。

不过说句实在的，这些优化里最管用的还是并行查询和直方图统计——这是MySQL 8.0才有的新特性，旧版本根本玩不了。现在回头看，半年前那个2.1秒的慢查询，要是没升级到8.0，光靠加索引和改SQL，最多优化到0.5秒，想进毫秒级？门都没有。

下一步打算研究MySQL的JSON字段索引——电商项目里订单扩展信息经常用JSON存，现在查询这些字段还是全表扫描，听说8.0.17之后支持生成列索引，或许能再砍点时间。不过话说回来，这些优化都有边界，真遇到千万级表，该分库分表还是得分，别迷信单库优化能解决所有问题。

（编辑：站长网）

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