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

　　上线那晚，我蹲在机房门口啃冷包子，设计站在楼梯口打电话，声音比MySQL慢查询日志还刺耳：“就按UI稿来嘛，圆角3px不能动。”后端叼着根没点的烟，在白板上狂画ER图，粉笔灰掉进领口里——白板右下角还留着上会写的“QPS峰值预估”几个字，早被擦花了边，像我们当时那点可怜的自信。

　　前年，崩得最凶那次，是改了个字段类型。本来 varchar(255) 存用户昵称，老板突然说要支持emoji，设计甩来张截图：日本客户头像底下挂着一串小星星小蘑菇，还标红写了“必须全显示”。后端说加长到500就行，我说行，顺手ALTER了。结果第七天凌晨两点，监控报警像丧钟一样响——主库LOAD飙到12，从库延迟滚到两小时，连登录页都刷不出来。我原以为是缓存雪崩，结果查binlog发现，光这一个ALTER就锁表俩钟头，期间所有写请求全堆在连接池里，连健康检查都超时。不是技术问题，是根本没人想过——这表有三千万行，而ALTER TABLE……在MySQL里根本不是“改个长度”，是抄家式重建。

　　第二坑是索引命名，说起来都想笑。我们管唯一索引叫“uk_user_email”，联合索引叫“idx_user_status_created”，听着挺规范吧？可半年后来了个新需求：按手机号+注册渠道查用户，得加个联合索引。后端提PR写着“idx_user_mobile_channel”，测试环境过了，上生产——完蛋，跟老索引前缀重了。MySQL不报错，它默默把新索引当成了老索引的“覆盖补充”，实际没生效。线上跑三天才被业务方发现：批量导出名单漏了一半人。后来翻源码才发现，那个“idx_user_”开头的索引早被删了，但名字残留还在建表语句注释里，没人动过。没人动，不是因为尊重历史，是因为没人敢删注释——怕删错。现在我看到任何带下划线的索引名，第一反应是摸手机看是不是有人刚离职。

　　第三个，也是最贱的一个：时间字段全用datetime，还默认填'0000-00-00 00:00:00'。不是不会用timestamp，是当年为省事，说“反正不涉及时区”。结果去年搞国际化，要加东南亚站点，运营半夜发微信问：“为啥用户昨天下单的时间显示成1970年？”——对，就是那个Unix元年。原来有个订单表的create_time字段被设了NOT NULL DEFAULT '0000-00-00 00:00:00'，PHP插数据时没传这个字段，MySQL就默默塞了个零日期进去。PHP读出来转Carbon，直接垮成1970年1月1日零点。我们排查了四小时，最后发现是ORM框架自动补了NULL，而MySQL又自动把NULL转成零日期……三层自动，一层比一层老实，合起来就是一场谋杀。

文章配图，仅供参考

　　测试群一直在响，我划了两屏没点开。窗外天黑了，路灯一盏盏亮起来，像数据库里一个个慢查询在排队点亮。我其实不怪设计非要圆角3px，也不怪后端没写DDL评审checklist——真要怪，得怪我们所有人，把“能跑就行”当成验收标准。半年崩一次？崩得勤是好事。上次回滚完，老板问我多久能修好，我说仨小时。他说：“别急，先吃饭。”外卖到了没人拿，塑料袋在会议室门口堆成小山，酸菜鱼汤都凉透了。我撕开筷子包装纸，忽然想起来，上个项目组那个爱改SQL执行计划的同事，上个月提了离职，走之前删了自己写的17条慢查询优化注释，只留一行：“此索引已过期，勿信。”

　　其实最该骂的是我自己。上个月又拍板加了个JSON字段存设备信息，理由是“前端随时要加字段，别来回改表”。现在那字段里塞着iOS版本号、屏幕宽高、是否启用了深色模式、甚至还有个嵌套的“ab_test_group”……说白了，我不信schema演化，我信的是“下次重构再说”。可哪有什么下次重构？只有下次崩溃。现在每天晨会，我都盯着慢查询日志刷新时间——不是等告警，是等它别太快刷出来。崩得越勤，活下来的表越结实；崩得越狠，敢乱改的人越少。优胜劣汰？不是系统淘汰人，是我们亲手用ALTER TABLE、用零日期、用下划线索引，把系统里的弱者一条条干掉，最后剩下一堆不敢动的古董表，和一群闻到ALTER就心悸的运维。

　　下周一我打算把那个JSON字段拆成三张小表。当然，还没跟后端说。他今早朋友圈发了张图：咖啡杯底印着“debug是人类最后的浪漫”。我点了赞，没评论。毕竟，浪漫归浪漫，明天早上六点，我还得去重启从库——这次不为修复，就为清空那个被撑爆的relay-log临时目录。这事儿，我也有份。

（编辑：站长网）

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