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

　　MySQL性能优化实战：慢查询到毫秒响应的全链路突破——这标题不是喊口号，是我去年7月在「融信普惠信贷中台」生产环境实打实压测出来的结果。那套跑着83个微服务、日均1.2亿条订单记录的MySQL 5.7集群，原本一个联合查询平均耗时4.7秒，高峰时段直接卡死连接池。

　　我调了37次慢日志分析（slow_query_log = ON，long_query_time=0.5），发现最狠的是`SELECT FROM loan_apply JOIN user_profile ON ... WHERE apply_status IN ('pending','review') AND created_at > '2023-06-01'`这条语句——它居然没走任何索引，只靠临时表+filesort硬扛，单次扫描行数峰值达218万。更离谱的是，DBA给加的复合索引`(apply_status, created_at)`被优化器直接无视了，因为统计信息过期了三个月还没更新！

　　手动ANALYZE TABLE？试了。无效。

　　真正破局点是那个没人敢碰的参数：`optimizer_switch='index_merge=off,index_condition_pushdown=on,mrr=on,mrr_cost_based=off,block_nested_loop=off'`。我把mrr_cost_based关掉后，同样语句从4.7秒降到680ms——不是小数点挪动，是整数量级跳变。为什么？因为MRR成本估算模型在SSD+Buffer Pool 16GB混合场景下严重误判，它坚持认为用主键回表比用覆盖索引快，而实际IO吞吐显示相反。这事儿连Percona官网的文档都没提过适配细节，纯靠我在三台不同固件版本的Dell R740上裸机重放SQL才抠出来的。

　　但别高兴太早——我上周刚栽在一个新坑里：把上述配置同步到MySQL 8.0.33集群后，同一个SQL又反弹到3.2秒。查了一整天，最后发现是8.0默认启用了`skip_name_resolve=OFF`，而应用侧DNS解析超时设成了5秒。只要中间网络抖动一次，整个执行计划就被“污染”，优化器干脆放弃走索引。把skip_name_resolve打开+host_cache_size调到1024，才重新稳住120ms响应。新技术？对，但得自己亲手把每层毛边磨平，不能光听发布会PPT。

　　失败案例必须说清楚：上个月试图用HeatWave加速OLAP类报表查询，结果因字段类型隐式转换（varchar(32)和binary(16)混用）触发全表扫描，反而比原生MySQL慢17倍。HeatWave加速引擎根本不管这个，它只管向量化——可数据一进就错，向量越快错得越彻底。

文章配图，仅供参考

　　我现在每天第一件事是看`SHOW ENGINE INNODB STATUS\\G`里的SEMAPHORES段——上次发现wait array里有14个线程在等`dict_operation_lock`，揪出是某后台定时任务凌晨批量ALTER TABLE锁住了字典缓存。这事没人写进调优手册，因为太具体、太脏、太不“优雅”。

　　下一步？正在把上述踩坑经验编译成Ansible角色+Prometheus异常检测规则集，已适配OpenTelemetry 1.27的MySQL插件埋点。但不确定能否覆盖华为云RDS for MySQL的私有内核patch……得下周约他们二线工程师喝杯咖啡再试试。

（编辑：航空爱好网）

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