MySQL性能优化实战：慢查询到毫秒响应全链路突破
|
MySQL性能优化实战：慢查询到毫秒响应全链路突破——这标题不是喊口号，是我去年春晚保障系统的真实战报。当时核心订单表单日峰值写入3800万行，凌晨0:23分一个LEFT JOIN+子查询的报表接口突然卡住，P99响应从120ms飙升到8.4秒，监控图上那根红线像被烫弯的铁丝。 我翻出慢日志发现：没走索引的WHERE条件里嵌着DATE_FORMAT(create_time, '%Y-%m-%d')，而create_time字段明明建了B+树索引。你猜怎么着？MySQL 5.7默认不支持函数索引下推——但文档里只说“部分函数可下推”，根本没列清单。我手写了一个生成日期维度表的脚本，把date_id提前算好存进订单表，再改成date_id = 20240210等值查询。改完第三天压测，该SQL从7.2秒干到46ms。新技术？就是得敢用Generated Column+STORED，而不是跪着求优化器猜你的心思。 上周三下午两点，某支付对账服务又崩了。查出来是JOIN两张亿级表时用了USING (order_no)，但其中一张表的order_no字段类型是VARCHAR(64)，另一张是CHAR(32)——MySQL内部会隐式转成VARCHAR(64)再逐字符比对，导致Buffer Pool里塞满临时排序页。我让DBA现场把CHAR(32)改成VARCHAR(32)，加了collation utf8mb4_bin避免大小写转换开销，同时用pt-archiver把历史数据按月归档。上线后QPS从820跳到3100，不过第二天发现从库复制延迟暴涨到27分钟——因为归档脚本没加--sleep 0.1参数，主库binlog刷得太猛，Slave IO线程根本抢不到磁盘IO带宽。这事暴露个赤裸现实：再牛的优化，跨不过硬件IO瓶颈。
文章配图，仅供参考 必须承认，有些场景纯靠SQL调优就是死路。比如我们去年接入某政务数据交换平台，对方要求每笔业务必须实时落库且保留原始JSON全文。结果insert into biz_log(json_data, timestamp) values('{"a":1,"b":2,...}', now()) 这种语句在高峰期直接触发InnoDB row lock等待队列雪崩——因为JSON字段太大，写入时undo log膨胀太猛，而innodb_log_file_size当时才48MB。后来硬是把json_data拆成schema化的字段存，用generated column自动补时间戳，再配合bulk insert+事务分片，才把TPS稳在4200。但这法子在客户现场根本推不动：他们连ALTER TABLE权限都没给运维……新技术确实管用。MySQL 8.0的invisible index、descending index、SET_VAR hint，还有Percona Server那些lock-wait timeout配置，都是真刀真枪能割开性能脓包的手术刀。但有个事我憋了很久想说：社区总吹Oracle的并行查询多厉害，可没人提他们为TPC-C压测特供的InnoDB page cleaner专用CPU核心——咱们用普通4核云服务器跑同样SQL，光是buffer pool mutex争用就吃掉37%的CPU time。所以别神话语法，先扒开top -H看线程ID再说话。 现在正盯着MySQL 8.4的LOCK_MODE=EXCLUSIVE选项实测效果，但客户下周就要上新版本K8s集群，我可能得先砍掉三个低优先级服务凑出资源做灰度验证。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
MySQL事务控制无障碍设计实战指南