MySQL性能优化实战：15年经验的全链路提速之道

　　MySQL性能优化实战：15年经验的全链路提速之道——这标题不是凑字数，是我去年2月份在某省级政务云平台真实压测后的命名依据。当时用的是MySQL 5.7.36，混合读写QPS卡在842就再也上不去，主从延迟峰值达142秒，而监控里InnoDB buffer pool hit rate只有89.3%。

　　我拆过37台线上数据库实例的slow_log——不是全量分析，是按“执行时间＞3.2秒+扫描行数＞12万”筛出前500条，发现63.8%的慢查询藏在JOIN子句后没加USING，而是靠ON a.id=b.a_id硬匹配；更隐蔽的是，其中21条SQL用了CONVERT_TZ()函数嵌套在WHERE条件里，导致索引完全失效——这个坑连Percona Toolkit的pt-query-digest默认规则都漏报了。

文章配图，仅供参考

　　去年2月份我在某电商大促前置压测中，把MySQL 8.0.28的cost-based optimizer（CBO）开关全打开，再配合直方图统计（ANALYZE TABLE orders UPDATE HISTOGRAM ON user_id, status WITH 16 BUCKETS），订单查询响应时间从均值417ms压到183ms；但第三天凌晨2:17突然发现支付流水表的INSERT并发跌了40%，查日志才发现直方图更新触发了全局MDL锁，锁住时间长达8.3秒——这细节连Oracle MySQL官网文档都没标红警告，只有DBA在凌晨三点盯着performance_schema.metadata_locks表才能亲眼撞见。

　　我干过最傻的事：给一个12TB的审计日志库开了innodb_file_per_table=OFF，结果optimize table直接让整实例挂了19分钟。后来重做时改用pt-online-schema-change分片收缩，单表操作耗时从计划14小时压缩到5.6小时，但代价是网络抖动导致2个分片binlog位点偏移错乱——我们最后是靠解析原始binlog里的XID事件+手动校验137万行checksum才找回数据一致性。这事我没写进任何述职报告，但至今我的备份脚本里还留着一行注释：“# 20230214-慎用optimize on >5TB table”。

　　有些方案听着漂亮实则害人。比如“所有WHERE字段都建单列索引”——我在华东某银行信贷系统见过127个单列索引挤爆了.ibd文件，buffer pool反而被索引页占掉61%内存；换成3个复合索引后，物理IO下降58%，但开发团队骂了两周，因为他们写的ORM动态SQL根本不会命中联合索引的左前缀……技术落地从来不是纯数学题。

　　MySQL性能优化实战：15年经验的全链路提速之道。我认为它优点在新技术——但这个“新”字，得配上你敢在业务低峰期删掉17个冗余索引的胆子，还得配上你愿意为一条执行计划多等40分钟看执行树展开的耐心。我最近正啃MySQL 8.4的WL#14240文档，里面那个自适应查询重写（Adaptive Query Rewriting）功能，目前只支持SELECT，INSERT还不认——所以到底该不该升？我现在每天上午10点跑一遍sys.schema_table_statistics_with_buffer，看哪张表正在悄悄吃光buffer pool……你呢？

（编辑：站长网）

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