加入收藏 | 设为首页 | 会员中心 | 我要投稿 站长网 (https://www.0516zz.com/)- 智能数字人、图像技术、AI硬件、数据标注、数据治理!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

MySQL运维设计避坑指南:14年DBA踩过的5大经典陷阱

发布时间:2026-10-28 08:13:05 所属栏目:MySql教程 来源:DaWei
导读:  上周三下午四点十七,机房空调又在抽风,右后方那台柜子嗡嗡声比平时高八度——我盯着主从延迟曲线炸开的尖刺,手边泡面汤都凉透了,油花浮成一片死灰。不是复制延迟,是应用层把主库怼到100% CPU后自己连不上,还甩锅给GTID

  上周三下午四点十七,机房空调又在抽风,右后方那台柜子嗡嗡声比平时高八度——我盯着主从延迟曲线炸开的尖刺,手边泡面汤都凉透了,油花浮成一片死灰。不是复制延迟,是应用层把主库怼到100% CPU后自己连不上,还甩锅给GTID不一致。我原以为是新上那个微服务加了全表update加锁逻辑,结果翻日志发现是开发本地测试环境直连生产库,用的是root账号,密码写在yaml里git push了三次……
  老张接了个电话,声音压得低:“运维组让先切读流量。”他讲完就把听筒转过来对着我,我听见对面说“DBA不背这个锅”。我盯着屏幕左下角时间跳到四点十九,顺手把桌角半块没拆封的薄荷糖塞进嘴里,甜味还没化开就吐了——太冲。


  第一个坑:用max_connections当安全网。去年七月修过三次同个问题:半夜三点钟告警,show processlist里三百七十二个Sleep状态连接,全是应用端没配连接池超时,数据库以为人还在,结果连接数卡死在2048。后来查出来是某SDK的druid配置漏掉testWhileIdle,他们改完,我第二天在工位吃煎饼果子,油顺着塑料袋流到键盘缝隙里,粘了三天。这个我敢打包票:只要你在my.cnf里调大max_connections来治“连接不够用”,你就已经输一半了。真要用?先把应用链路里所有close()调用打点,再去看哪个接口的finally块里写了return没执行close。别信“框架自动回收”——框架只管扔垃圾,不管收尸。


  那天雨特别急,窗沿积了水,一滴一滴砸在机柜散热口金属挡板上,嗒、嗒、嗒,像在敲倒计时。我蹲着看主库IO等待堆积到四十毫秒的时候,王工拎着保温杯路过,拧开盖子喝了一口,突然说:“要不要试试ProxySQL?”我没理。不是不想试,是他上个月刚在测试库把read_only=ON设成OFF,导出语句删了十万条订单——他自己写的备份脚本,grep -v “delete”但忘了中间有空格。所以现在他提啥我都慢半拍。


  第二个坑:用pt-archiver做归档,却忘了主键不是自增。上个月处理一个日志表,三十亿行,归档到历史库,脚本跑两小时突然卡住。查发现where id > xxx and id < yyy 里的yyy被pt自己算错了——它依赖explain估算行数,而那个表统计信息半年没更新过,直方图还是创建当天的。最后硬切到mysqldump --where,一行一行撸。那天我穿着拖鞋来的,左脚拖鞋带断了,踩着半截胶皮去机房,走到第三排机柜时,右脚踩到地上没擦干的水渍,滑了一下,扶住了冷通道玻璃门,门晃得厉害。我其实不怪pt工具,怪自己没在归档前先run analyze table;但更怪的是没人问一句:“这表主键是UUID,你还敢信range estimate?”


  第三个坑最恶心:字符集。MySQL 5.7默认utf8mb4,你们知道,但应用连的是latin1连接字符串,然后字段建的是utf8mb4_general_ci——你插入emoji存进去,select出来变? ? ?,开发说前端没传对,前端说后端解析错,后端说DB返回乱码。我上次处理这个花了十八秒定位:show variables like ‘%character%’,对比客户端、连接层、表级三个层级。可你知道我在干嘛吗?我在看那个实习生小陈怎么用Navicat点鼠标选编码。他点了三次才点对,第四次又点回gbk,我忍住没说话。后来发现他电脑壁纸是《流浪地球》里刘启那张剧照,桌面图标堆得密不透风,连回收站都看不见——这种人不该碰线上库,该去调显示器亮度。


文章配图,仅供参考

  第四个坑:binlog_format=MIXED。这个我现在看见就想按电源键。MIXED听着平衡,实则哪头都不救。前天线上insert … select 走了STATEMENT,主库OK,从库报错Duplicate entry;换ROW?又卡住磁盘IO。最后换成了ROW+binlog_row_image=FULL,结果磁盘爆满——因为有个字段是TEXT类型,每行改一次就整个列记进binlog。我们当时就在DBA群里发了个截图:/var/lib/mysql/binlog/ 前缀文件占了93%,有人回“清一下啊”,我说“删了从库就永远追不上了”,群里安静了四分钟。后来老李说他老婆今天生日,他得赶八点前回家,说完就下线了。


  第五个坑我不细说了——监控埋点全靠show global status轮询,而这个命令本身在高负载下就会卡住Performance Schema。你猜我昨天怎么发现的?巡检脚本报超时,我看进程里堵着十七个show status,每个等了二百多秒。我直接kill -9掉五个,剩下十二个自动解开了。这不是故障,这是设计债。就像你装修房子,把所有插座都安在墙角,十年后买台扫地机器人,发现它卡在玄关第三块瓷砖那儿永远转不出来。这个我说不准它是不是MySQL的问题,还是我们的习惯太老——反正我今早又在监控面板加了个指标:Threads_running > 150 持续三分钟,自动发钉钉@所有人,消息末尾带了个emoji:????。但其实钉钉通知也偶尔丢,上周二就丢了两次,我查了一小时才发现是群聊设置了免打扰,静音图标藏在右上角小箭头后面。


  哦对了,今天早上六点半收到邮件,说AWS RDS自动升级MySQL 5.7.42到5.7.43,补丁里修复了一个replication crash bug。我点了“推迟7天”,然后关掉邮箱页面,没点刷新。桌上外卖盒还开着,里面是葱油拌面,青菜蔫了,面条坨在一起,酱油沉底。我不打算重做一遍变更评审——这版本号听着就没事,再说,出问题也是RDS团队兜底。但我知道,下周二之前,我得把所有binlog校验脚本的md5比对逻辑重写一遍。先这么着吧。

(编辑:站长网)

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