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

去年6月份，我接手了一个电商系统的MySQL优化项目——用户反馈结算页加载要5秒，订单查询接口超时率高达12%。当时团队试过加索引、拆表这些常规操作，但QPS超过800时，数据库CPU直接飙到95%，慢查询日志里全是全表扫描的记录。这哪是优化？分明是给漏水的船补窟窿。

我盯着监控面板看了俩小时，发现个诡异现象：某条订单查询SQL在凌晨3点执行只要18ms，高峰期却要2.3秒。EXPLAIN一看，好家伙——type列全是ALL，key列空着，rows列显示要扫800万行。这SQL用了LEFT JOIN关联了7张表，其中3张表根本没参与筛选条件，纯粹是业务代码里"以防万一"加的冗余字段。砍掉这些无效关联后，单条SQL响应时间直接掉到120ms，但QPS到1200时又开始卡顿——这时候才发现，索引虽然建了，但复合索引的顺序是错的，把低区分度的字段放在了第一位。

真正的突破来自新技术——MySQL 8.0的直方图统计和并行查询。传统优化靠猜，现在能直接用ANALYZE TABLE生成字段值分布直方图，优化器能精准判断用哪个索引。比如用户表有个"last_login_time"字段，原本以为按时间范围查询该走索引，结果直方图显示80%的数据集中在最近3天，优化器果断选了全表扫描+内存排序——这操作要是搁以前，早被运维骂"乱搞"了。并行查询更狠，对大表COUNT()这种操作，设置innodb_parallel_read_threads=4后，原本4.2秒的查询变成890ms，CPU利用率从单核100%变成四核各25%。

但新技术不是银弹——我踩过个大坑。有次为了用并行查询，把innodb_buffer_pool_size从12G缩到8G，结果高峰期缓存命中率从98%掉到72%，磁盘IO直接打满。后来发现并行查询虽然快，但需要更多内存缓存中间结果，最后把buffer_pool调回16G，并行度设为2，才达到性能和稳定性的平衡。这就像调CSS动画——知道transform比left性能好没用，得实际测不同属性的重绘代价。

文章配图，仅供参考

现在系统QPS稳定在2500，结算页平均响应87ms，但我知道这还不是极限。最近在研究MySQL的JSON字段索引和函数索引——用户表里有个"tags"字段存的是JSON数组，之前用LIKE '%vip%'查询要走全表扫描，现在用Generated Column+索引，能把这类模糊查询干到50ms内。不过这玩意儿得MySQL 5.7.9以上版本，老系统升级得谨慎——我见过因为JSON字段索引导致主从同步延迟的案例，那场面，比CSS的z-index冲突还难搞。

下一步打算把慢查询日志接入Prometheus，用Grafana做实时告警——现在还是靠人工巡检，漏掉几个异常SQL就可能引发雪崩。对了，你们谁试过用ClickHouse做MySQL的查询加速层？听说对聚合查询有奇效，但担心数据同步延迟的问题——有实战经验的麻烦私信我，这坑我先帮你们踩了。

（编辑：草根网）

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