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

　　去年清明节，服务器在雨里喘了十八秒，然后断了。老张蹲机房门口抽烟，烟头明明灭灭，跟监控屏上那个疯狂跳红的 MySQL 连接数一模一样节奏——我敢打包票，那会儿他左手第三根手指在抖，不是冷的，是刚被DBA甩了一脸“你这表结构谁审的”。

　　不是慢，是崩。崩得特别有规律：半年一次，不多不少，像老钟表，锈死前还准。上季度末运维小刘凌晨三点爬起来重刷从库，边刷边嘀咕“这主键ID又穿了”，我听见了但没接话——上回我说“改成bigint试试”，他白了我一眼，顺手把泡面盒塞进垃圾桶，盖子没盖严，汤水漏了一地。那会儿空调坏了，机柜嗡嗡响得像拖拉机挂了二挡。

　　第一个坑：TEXT 字段当筛选条件。不是不能用，是你真用了——“用户标签”那个字段，我们存的是JSON字符串，建了个FULLTEXT索引，还沾沾自喜。结果去年清明那天凌晨，运营临时要查“最近七天打过标签且含‘付费’关键词的用户”，SQL跑出来三分钟，连接池直接满。我原以为是缓存没打透，结果看执行计划，type=ALL，key=NULL，Extra里赫然写着“Using filesort; Using temporary”。老杨当时在隔壁工位改一个安卓4.4的flex兼容，听见我骂娘，探头问：“你这个TEXT是哪个字段？”我说“tag_info”，他愣了两秒，扒拉手机翻出他去年双十一写的埋点上报代码，指着一行注释念：“别在where里碰text……你真没看文档？”

文章配图，仅供参考

　　第二个坑：时间字段用VARCHAR(19)存'2023-04-05 14:22:37'。没人说它错，连MySQL都默许。可上个月数据核对，财务组发现订单完成时间比支付时间早三分钟——不是逻辑错，是排序错。VARCHAR按字典序排，“2023-04-05 14:22:37”和“2023-04-05 9:22:37”比大小？后者排前面。DBA导出时用了ORDER BY create_time DESC，结果最后一条其实是凌晨四点下的单。那个下午阳光特别刺眼，财务妹子推眼镜的动作很重，镜片反光盖住了她半张脸。我没吭声，因为我知道，三个月前我就在review里批过这一行，写的是“建议改DATETIME”，后来被人删了，留言里只留了仨字：“没必要。”

　　第三个坑：分表不分库，还用同一套连接池。我们分了128张user_order_000到user_order_127，看着挺猛。可上周五，某个运营活动上线后，所有请求全砸到user_order_063上——为什么？因为那个渠道码的hash值刚好全落在063。连接池撑不住，报错堆里混着二十多个线程卡在`waiting for table metadata lock`。那天我盯着日志看了四十分钟，直到外卖凉透。盒子上印着“饿了么·清明特惠”，日期是4月3号。盒盖掀开，葱花浮在汤面上，一圈圈散开，像慢放的锁等待超时。

　　最扯的是，崩完重启，数据没丢，业务能恢复，就是用户发个评论得等三秒。没人提重构表结构。产品说“先加机器顶住”，运维说“下周排期加读从库”，而我昨天收到一封邮件，标题是《关于优化用户中心服务响应的二期规划》，附件PDF第17页，画了个漂亮的微服务分层图——底层数据库层，依然写着“MySQL集群 v5.7”，下面没标引擎、没标索引策略、没标任何约束，只有一行灰色小字：“高可用架构已通过验收。”

　　其实崩得越勤，越说明活着。要是真半年没动静，才该怕——要么没人用了，要么数据早就不动了。我们那个063分表现在加了单独连接池，但配置文件里还写着“maxActive=20”，我昨天下班前偷偷改成30，没PR，就vi进去改了，保存时手抖按了两次ESC，光标闪了好久。对面坐的老王正在调一个React组件的z-index层级，耳机线垂下来，缠住咖啡杯把手，他拽了三次才解开。

　　你说这些坑为啥半年一踩？因为上半年都在救火，下半年才想起来翻DDL。而且——你信不信？只要新来的产品经理还没催第二版需求，技术债就能再活四个月。我原以为换掉主键就能稳，结果发现那个bigint列，从库里抽出来的值，前端JS里一parseInt，溢出了。老杨看见后，没说话，只把调试器console.clear()摁了三次，清掉所有log，然后切到另一个tab，开始查Chrome安卓版的Date.parse兼容性表。

　　这事儿我真不敢打包票能改完。上周末我试过改text字段成JSON类型，ALTER TABLE语句跑了俩钟头，中间停电三秒，UPS响了，机房灯全黄了，等再亮起来，那个session已经断了，DDL卡在half-baked状态。后来DBA重做了表，但备份时发现binlog里有一条UPDATE是跨表的，没走事务，也没日志标记。这事我不打算追了——下个月，可能又要清明了。

　　我现在改了个习惯：每次建表前，先把CREATE语句贴进测试环境，执行完，立刻查information_schema.columns，数三遍字段顺序。不是怕错，是怕自己忘了哪年哪月在哪张表里，埋过一颗叫“临时方案”的雷。桌上的薄荷糖化了一半，在手机壳背面黏着，我抠不下来，就让它粘着。

　　今晚我准备去改那个tag_info字段。不换类型，就加个generated column + index，先扛过五一。如果真崩了——嗯，我打算让老杨帮忙写个前端兜底，加载失败时显示“网络波动，请稍候，顺便测测你手机CPU温度”。反正他上次测安卓4.4的帧率，也靠手摸机身。

（编辑：站长网）

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