站长必避的3个MySQL设计陷阱：半年一崩

　　去年十月十二号凌晨三点二十，我正蹲在IDC机房第三排冷通道里，左手捏着刚撕开的红烧牛肉面调料包，右手举着测温枪对准MySQL那台戴尔R730的后盖风扇——呼啦啦全是热风，像烤箱门一拉开。监控屏右下角贴着半截蓝色电工胶布，遮住上周被磕掉的像素点，底下数字跳着：磁盘使用率97.3%。我没动。我知道它还能撑两小时，可我心里发毛。

　　就在这时候，老板在运维大群甩了张截图：“网站打不开？！”后面跟着个爆炸表情。我没回。群里秒沉，只有客服小陈发了个“？”又撤回，再发：“用户说登录页空白，刷新五次。”我盯着她头像旁边那个灰色的“在线”，忽然想起上个月搬家，纸箱里漏出半本《高性能MySQL》第三版，扉页写着“2015年购于中关村e世界”，书脊裂了三道口子——这书我早不翻了，翻了也没用。

　　第一个坑是日志表没加归档策略。不是没设过，是设了又删了。去年三月上线那会儿，DBA老周拍胸脯说“先用truncate weekly，稳得很”，结果他八月跳槽去了字节，走前把crontab里那行脚本删了，只留了个注释：“待优化”。没人动它。半年过去，mysql-slow.log和error.log全塞进/var/lib/mysql目录下，跟ibdata1肩并肩躺着。我昨天查的时候发现——慢日志文件名叫mysql-slow.log.20231008.gz，而真正跑着的日志是mysql-slow.log.20231012，中间四天根本没压缩，连轮转都没触发。我原以为Linux内核会帮它扛一下，结果它连open()都失败了，报错居然是“Too many open files”，可ulimit -n明明设到了65536。这个我到现在也没想明白。

文章配图，仅供参考

　　第三个坑最贱：主库开了log_bin，从库却没配replicate-ignore-db=mysql。表面看没毛病，毕竟没人往mysql库里写数据。可上周站长升级了WordPress插件，插件偷偷往mysql.user表插了两条测试用户，没走SQL审核平台，直连root执行。那两条INSERT瞬间被主库binlog捕获，发给从库——从库懵了，自己改自己权限表？直接IO线程卡死，Seconds_Behind_Master标成NULL。等我发现时，从库已经十七个小时没同步了。主库还在吐新日志，磁盘像吸水海绵一样鼓胀。我重启slave线程，它吐出一句“Duplicate entry ‘wp_plugin_test’ for key ‘PRIMARY’”，然后沉默。小李在隔壁工位喊我：“你那边CPU飘红了？”我没应。CPU飘红不重要，磁盘才是定时雷。

　　其实十月十号我就看见磁盘告警邮件了，红色，标题“HIGH: /var/lib/mysql usage >95%”。我点了已读。不是不想处理，是那天下午厂商工程师来了，非要在我机器上装他们家“智能SQL优化助手”，后台起三个Docker容器，吃掉2G内存，还弹窗问我“是否允许采集慢查询样本”。我点了否。他叹了口气，说“那你们自求多福吧”。我笑了一下，手抖着把他的U盘格式化了——就顺手，不是针对谁。

　　凌晨四点零七分，磁盘爆了。先是HAProxy开始503，接着K8s里所有依赖MySQL的Pod疯狂CrashLoopBackOff，kubectl describe pod只显示“Back-off restarting failed container”，再深一层日志得进容器里看，可容器进不去——宿主机df -h直接卡死三分钟。我掐着表，四十来分钟里干了三件事：第一，拔掉备用从库网线，怕它同步最后一段脏数据；第二，ssh进主库，手动删掉/usr/local/mysql/logs下的七个.gz包，删完才想起它们根本不在/var/lib/mysql下；第三，给小陈发微信：“跟用户说‘系统维护中’，别提数据库。”她秒回：“好。顺便问下，我娃明天幼儿园秋游，能请半天假吗？”

　　我盯着手机屏幕，突然想起老周离职前喝醉那天，在烧烤摊上扒拉着签子说：“现在做站长，一半时间在修MySQL，一半时间在解释为什么修MySQL要花三天。”他当时笑着，油光满面。我点点头，没接话。那会儿我以为他是抱怨工作琐碎，现在明白了——优胜劣汰不是筛技术，是筛谁敢在磁盘剩3%时，还敢把slow_log路径硬怼进datadir底下。

　　监控屏右下角那块蓝胶布，边角翘起来了。我拿指甲抠了抠，没抠下来。明天先把告警阈值从95%调到88%，就今天这劲儿，它撑不到下周二。

（编辑：站长网）

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