6年MySQL运维实战：慢查询到毫秒响应

　　6年MySQL运维实战：慢查询到毫秒响应

　　去年2月份，我接手某电商订单中心的慢查治理——那个库跑着MySQL 5.7.28，主从延迟峰值到143秒，最慢的一条SELECT COUNT() FROM order_detail WHERE create_time > '2023-01-01' AND status IN (1,2,4)用了37.6秒。索引明明建了，执行计划却死活不走联合索引，explain显示type=ALL。抓包发现应用层每分钟发127次这个SQL，而它本该被缓存——可他们用的是MyBatis二级缓存，key拼接逻辑漏掉了分页参数，导致缓存穿透。我们临时加了个Redis兜底，但真正起效是把create_time字段从DATETIME换成BIGINT存储毫秒时间戳后重写查询——响应压到了89ms。新技术？当然。但这技术两年前就写在MySQL官方文档里，只是没人敢动生产环境的时间类型。

　　6年MySQL运维实战：慢查询到毫秒响应

　　去年2月份，我把某物流轨迹库从MySQL 5.6.36升级到8.0.32，顺便启用了直方图（ANALYZE TABLE t_track UPDATE HISTOGRAM ON event_time, status WITH 64 BUCKETS）。结果一个原来需要11秒的“查询最近7天异常轨迹点”语句，优化器突然选对了索引，执行时间缩至210ms。但三天后监控报警：备份时长翻倍——因为8.0.32的mysqldump默认开启--skip-tz-utc，而他们的Docker容器没配TZ环境变量，导致每个TIMESTAMP字段反复转换时区，单表导出多耗17分钟。最后手动加--tz-utc才救回来。新技术？确实快。但它会咬人，尤其当你没在测试环境跑够72小时全链路压测的时候。

　　失败过一次。

　　去年2月份，为金融对账库引入Rockset做实时物化视图，想替代原来凌晨3点跑的23个SUM+GROUP BY聚合任务。我们花两周把MySQL Binlog解析接入Flink CDC，再推到Rockset。上线首日，一条涉及跨月币种汇率换算的查询返回了2.3%的偏差值——追查发现Rockset默认按UTC分区，但原始MySQL时间字段是Asia/Shanghai，且Flink水位线未对齐日切点。更坑的是，他们的业务同学把Rockset当MySQL用，在WHERE里写了DATE_FORMAT(create_time, '%Y%m%d')，而Rockset不支持这个函数，悄悄转成字符串比较，把2024-02-29这种不存在的日期也纳入了结果。最终灰度回退，用原生MySQL+覆盖索引硬扛。这事儿让我认清一点：所谓“新技术”，不是看文档写得多炫，是看它在你那条脏数据、那个没设timezone的crontab、那台NTP漂移0.8秒的物理机上，到底肯不肯吐出准数。我认为它优点在新技术——但这个“新”字，必须贴着你凌晨三点盯着Prometheus面板发红的眼睛来定义。

文章配图，仅供参考

　　去年2月份接手的医疗影像系统，至今仍有三张大表没完成在线DDL——不是不能，是不敢。因为其中一张patient_series_log表，单日写入量420万行，pt-online-schema-change执行期间，主库IO wait一度飙到92%，从库复制中断两次。现在改用gh-ost，但切表窗口只能卡在凌晨1:15–1:28这13分钟，还得同步盯住Percona Toolkit的chunk进度和Binlog GTID gap。上周试了MySQL 8.0.33的INSTANT ADD COLUMN，结果发现它不支持TEXT列所在的表——而这张表恰好有三个TEXT字段存DICOM头信息。所以……下一步先写个Python脚本自动识别TEXT列依赖，再决定要不要拆表。或者，真要试试TiDB？听说他们那边同事上周刚把类似场景从14秒干到168ms，不过他们没提是否顺手干掉了所有外键约束。

（编辑：站长网）

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