站长必避的3个MySQL设计陷阱

　　线上出问题的那一刻，我正盯着编译进度条卡在92%——不是Webpack，是那个破CI里顺手搭的MySQL schema diff脚本，跑完要等两分半。后端蹲在工位边上说“查不到session_id”，我说“查什么查，show processlist都堵成毛线团了”。他刚张嘴，产品在群里甩截图：“首页UV掉37%”，设计立刻回了个捂脸表情包，我顺手点了保存——现在它还在相册里，带EXIF时间戳。

　　第一个陷阱？varchar(255)当祖宗供着。半年前上线那个新后台，所有字段全是255，美其名曰“兼容未来扩展”。结果导了一周用户行为日志，单表涨到47GB，磁盘IO直接贴天花板。我原以为是索引没建好，调了三版执行计划，改了两次buffer pool size……最后发现是text字段硬塞进varchar(255)，二进制乱码截断+隐式转换，连explain都骗你。谁定的？就是设计提需求那天下午，我边听边敲键盘，他指着Figma上那个“备注框”说“够用就行”，我没拦。现在够不够用？够。快不快？快个屁。这不是技术问题，是驯化失败——你让站长拿MySQL当Excel用，他真就当Excel用。

　　窗外在下雨，雨刮器节奏像我心跳。第二个是自增ID。不是反对自增，是反对只用自增。上周灰度发版，订单表崩了两次，查下来全是insert冲突：不是主键重复，是分布式插入时snowflake生成的order_id和本地auto_increment撞车，timestamp部分秒级相同，微秒对不上——我们压根没开ROW_FORMAT=COMPRESSED，也没配innodb_autoinc_lock_mode=2，就靠一个锁等。后端当时说“先加读锁扛过去”，我说“你加锁的时候订单已丢，再扛也是给监控刷KPI”。我原以为只要uuid短一点就稳，结果测试环境跑通，上线秒跪。uuid_short？不行。雪花算法自己撸？更不行。最后认栽，换bigint + 业务分段分配——但站长要的不是分段，是他点个“新建”就出来一串看得懂的数字。我们妥协了，他没妥协，所以优胜劣汰这词儿站得住：留下的库，都是把自增当哑巴用、敢砍ID字段语义的。

文章配图，仅供参考

　　旁边工位风扇声忽大忽小，像接触不良。第三个最烦：JSON字段当兜底神器。产品经理上个月改了三次埋点格式，每次都说“前端传啥后端存啥”，我们真就建了个json_text列，default NULL，连CHECK约束都懒得写。结果某天凌晨白屏报警，溯源发现是某个埋点字段嵌套太深，MySQL解析JSON时内存爆了——不是OOM，是线程栈撑到1.8GB，直接被OS kill。我翻了下错误日志，第7行写着“out of memory in JSON parser”，第8行空着，第9行是我写的注释：“这玩意儿能查？”。查不了。explain都不理它。但站长爱它啊，字段名不用提前想，上线不用改DDL，热更新就像呼吸一样自然。热更新完呢？查不出来。查不出来呢？打补丁。补丁越打越多，直到有人发现——哦，其实当初建表时把event_type、event_time、event_payload拆成三个列，加个联合索引，慢查询从2s降到6ms。但没人干。因为“改表要停服务”，而停服务，等于今晚加班费报销不了。

　　昨天HR在招聘群甩了份JD，要求“熟悉MySQL执行计划、有TB级分库分表经验”，我回了个“贵司招的是DBA还是扫地僧”。没人接话。后来我自己删了。其实我想说：真正毁掉MySQL的，从来不是JOIN太多，也不是没加索引，是站长们在原型评审会上点头说“这个字段以后可能要存多种类型”，然后工程师就默默建了个JSON——那不是懒，是共谋。大家心里都清楚这东西迟早裂开，但裂开那天不在今天，不在本周，大概率也不在我交接之前。认了。

　　我打算下周把那个埋点表拆了。不全拆，先拆event_payload，抽三层常用字段建物理列，剩下扔JSON，加个触发器自动更新ts_update。可能又错，可能白干。但至少——比等着白屏报警强。对了，外卖到了，红油抄手，汤都凉了。我不动筷子，先看一眼innotop里thread list的State列有没有卡在Sending data……

（编辑：我爱资讯网）

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