MySQL运维与设计五大致命陷阱揭秘

　　后台数据不对那一刻，我正叼着半截烟盯屏幕，右下角MySQL连接池那行数字突然飘红——不是报错，是慢得像卡在毛细血管里，查个user表要八秒。我原以为是索引失效，结果一扒慢日志，发现主键上堆了三个联合索引，其中一个还是 (status, created_at, id)，id在最后？我盯着那行DDL看了三分钟，手抖把烟灰弹进键盘缝里。

　　去年7月份，甲方凌晨两点发来截图：“你们这订单状态根本不同步。” 截图里两个库的order_status字段，一个写“已发货”，一个还卡在“待审核”。销售当时在群里甩话：“客户说再不修今天就砍单。” 我没回，把笔记本合上推到一边，空调冷风直往后脖颈钻，窗外天黑得特别早，像谁提前按了开关。

　　其实不是同步问题。是设计陷阱——我们那个“订单状态机”压根没用状态字段，全靠event_log表里的type+payload拼凑状态。开发觉得灵活，运维看吐了。那天我翻了三天日志才定位到，一笔退款事件触发了两次insert，但第二次因为主键冲突被静默吞掉，status就永远停在半路。我原以为是binlog传输延迟，结果查到中间件层发现它把重试逻辑写进了事务里……人还在那儿笑：“哎呀，这样不容易丢事件嘛。”

文章配图，仅供参考

　　反常识结论是：越怕出事，越容易栽坑里。比如那个被捧成银弹的“分库分表”，我们上个月刚拆完一个单表五千万的订单库，结果发现分片键选的是user_id——可80%的查询都是按order_no查！现在查单要扫八个库，加缓存都救不回来。我提过一次改，技术总监直接拍大腿：“你不懂，分片键必须跟业务主键强耦合！” 那天他桌上泡面盒还没收，汤都凉透了，我默默把会议纪要说成“暂不推进”。

　　午饭吃的是楼下那家兰州拉面，老板换人了，面汤淡得像涮锅水。坐我对面的同事扒拉着面说：“前两天线上崩了半小时，查到最后是那个‘全局唯一订单号生成器’——用了UUID_SHORT()，结果MySQL时钟一漂移，就返祖到1970年，生成了一串零开头的鬼数字，所有下游服务全懵了。” 我筷子顿住，心想：这玩意儿当年评审文档里写着“兼容性强、无中心依赖”，结果兼容的只有Unix纪元……

　　还有那个天天喊“高可用”的从库。双主架构，但读写分离策略是代码里硬写的——所有select语句默认走从库，除非显式加/FORCE_MASTER/注释。结果某次新功能上线，测试没覆盖注释语法，一行SQL少打了斜杠，整条资金流水走到了从库。数据倒是没丢，就是延迟了四十七分钟。甲方打电话来时我在修打印机——纸卡住了，和那四十七分钟一样卡得死死的。同事探头问：“要不要重启从库？” 我摇头，把打印纸抽出来，折成小船放在窗台上，忘了它会自己飞走。

　　最狠的是那个“自动扩容脚本”。DBA写的Python脚本，监控到CPU超70%就自动加节点，逻辑清清楚楚：查processlist > 200 → 加只读副本 → 等sync完成 → 切流。问题是它没判别长事务。那天一个备份作业卡住，processlist飙到380，脚本唰唰起了四个新实例，全堵在复制位点上。后面三小时，每笔写操作都带着锁链跳舞，客服电话炸了。我原以为是网络抖动，结果tail -f error.log里全是“The slave I/O thread stops because master and slave have equal MySQL server ids.”——新加的四个节点，server_id全设成101，撞得明明白白。

　　办公室空调太冷，我裹着薄外套改配置。改完一试，主从又断了。这次报错更绝：“Authentication plugin 'caching_sha2_password' cannot be loaded.” 公司统一用8.0，但那个备份脚本里yum源写的还是5.7镜像，起的新节点装的是降级版MySQL，密码插件不认。我盯着错误提示笑了两声，嗓子发干。销售在隔壁工位接电话，声音大得盖过键盘声：“您放心！绝对今天内解决！”——其实那天根本没解决，只是把告警阈值从70%调到了90%，让报警晚来了两小时。

　　我最近在试个土办法：把所有DDL加进Git，每次合并必须三人会签，签名格式是“已确认未踩五大坑（附checklist）”。第一条就写：“禁止在高频update字段上建函数索引”——上周有哥们儿给price字段建了个abs(price)索引，说为了支持负数价格查询。现在每次价格变动，索引重建占满IOPS，连备份都不敢动。我删索引那天顺手删了自己微信里六个DBA群，退出时最后一眼，有人正发图：“刚跑通TIDB自动扩缩容。”

　　反正现在，每次看到建表语句带DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，我就先点根烟。不是反对时间戳，是怕后面人看不懂为啥updated_at比created_at早两秒——上次是因为时区没统一，应用层设UTC，数据库配的是上海时区。我打算下个月拿这套检查清单糊到公司茶水间，旁边贴张便签：“谁敢绕过，奶茶钱他请”。当然，也可能没人理，就像上回我提“该把innodb_buffer_pool_size从12G调到32G”，运维老哥一边打哈欠一边敲enter：“哦，先放那儿吧。” 屏幕蓝光映着他眼角的细纹，像一道没填平的分区键。

（编辑：站长网）

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