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

　　我原以为那个主键自增字段加了唯一索引就稳了，结果去年四月灰度第三天，订单号重复俩，一个发到张磊客户那儿，一个发到李薇客户那儿，她俩还同时在微信里问“怎么同一单收两次款”。

　　会议室又被占了，门缝底下压着张纸条，字迹像没睡醒——“借15分钟，OKR对齐”，我蹲着把纸条塞回去的时候，白板上的数字擦了一半，剩个“37”和半个“.”，不知道是覆盖率还是bug数。

文章配图，仅供参考

　　站长必避的3个MySQL设计陷阱：半年一崩的真相。不是玄学，就是优胜劣汰——扛不住半年的架构，要么自己改掉，要么被线上日志吞掉，没第三条路。

　　第一个坑是text字段当where条件。开发说“只是查一下简介关键词”，行，你查，但没建前缀索引，也没加冗余字段。我漏测过一次，漏在回归范围里写了“不走全文检索路径”，可用户偏偏在搜索框打了个“MySQL设计陷阱”，七个字，刚好卡在InnoDB默认前缀长度之外。那天用例管理工具一直在转圈，我点三次才弹出“执行中…”，等它跑完，数据库连接池已经满了两轮。

　　键盘上有个键按下去不回弹，Q键，按十次八次才出一个q，我打“SELECT FROM order WHERE remark LIKE '%陷阱%'”时，手抖多敲了个空格，SQL跑了47秒。DBA凌晨两点打电话来，说慢查日志里这句出现19次，全堵在从库。我没接他后半句“建议加覆盖索引”，只问他：“那remark字段是不是从来就没进过DDL评审？”他顿了三秒，说“上个月你提的那个变更单，我批了‘评估中’，然后……没了。”

　　第二个坑是时间字段用datetime存毫秒。开发说“前端传来的ISO格式，直接塞进去最省事”。我信了。结果上线后第三周，用户投诉“预约时间总错23小时”，不是四舍五入，是固定偏移。查日志发现MySQL 5.7在跨时区insert时，如果时区配置是+08:00但客户端连的是UTC，datetime字段会把毫秒部分截断再强转——不是精度丢失，是整段抹掉。我翻到那个迭代的部署包，里面my.cnf里timezone=SYSTEM，而system时区在docker容器里其实是UTC。谁桌上摆着三台手机，屏幕朝上亮着，分别是测试、预发、生产环境的监控钉钉群，全是红色未读。我点开生产群，最新一条消息是运维发的：“主库CPU爆表，疑似触发临界锁等待。”没写哪张表，但我知道，又是order_time那个字段。

　　外卖凉透了，铝箔盒底凝着一层油，像薄冰。我扒拉两口，饭粒粘在盒沿上，没胃口。想起上周跟开发争执，他说“反正有幂等”，我说“你幂等逻辑校验的字段，根本不在联合索引里”，他反问我“你见过哪个业务不重试？”——我见过，就我们这个支付回调。漏测案例：回调请求带着同一个out_trade_no冲进来，数据库没锁住，两条成功记录进了表，财务对账差八千六，最后靠人工捞日志填平。不是代码问题，是表结构里out_trade_no没设唯一约束，只加了普通索引。

　　第三个坑是分表键和查询键完全错位。站点搞了个user_id分片，结果90%的报表查询都按create_time倒序取，每次都要扫所有分片，合并再排序。去年四月那次崩溃，就是运营半夜跑了个“近半年注册用户活跃趋势”，一查就是三分钟，下游服务全部timeout熔断。DBA拉我去看explain，type=ALL，rows=327万，key=null。我盯着那个null看了半分钟，想起灰度前夜，开发在群里甩链接说“已验证分页性能”，点进去看用例写的却是“limit 20 offset 0”，没写offset 1000000的场景。我原以为这种边界case早进冒烟了，结果用例文档里连“大偏移量”四个字都没出现过。

　　测试机的充电线不够长，扯到桌子边缘悬着，每次有人路过都得绕一下，怕踢到。上个月我把它缠在鼠标垫底下，现在接口响应延迟高了300ms，不知道是线压着USB口了，还是真碰上数据库连接泄漏了。

　　自己那份没人看的用例。上周发了个新版，把“分页偏移大于50万”的case补全了，加了五个分支路径，邮件抄送全员。今天早上看见产品在群里@所有人，“下期重点支持新老用户转化漏斗”，附件是PRD，正文没提任何数据口径或分页逻辑。我截图发给开发，他回了个????，没点开PDF。

　　漏测的复盘会上，李薇说“当时测试环境只有50万测试数据，跑不出慢查”，我接话说“所以你当时知道压测数据量不足？”她摇头：“我不知道要压多少，只知道验收标准里写了‘页面秒开’。”我顿了一下，没往下说——验收标准是我写的，“秒开”后面括号备注了（首屏渲染

（编辑：站长网）

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