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

　　一三年那会儿，我跟老陈蹲在西直门那个朝北的小屋里改表结构，窗户缝漏风，风扇在头顶嗡嗡响，他叼着烟把SELECT FROM posts写成存储过程，说“以后肯定要分库”。我信了。桌上那台飞利浦显示器右下角有道裂纹，反光时像条细蚯蚓——这细节我记得清，可到底是从哪年开始不用存过程的？记混了。一四年？还是一五年？反正后来发现MySQL 5.6开始支持在线DDL，我们那套先锁表再改字段的土办法，早就该进废纸堆。

　　一七年在望京，带俩实习生做内容站迁移，主键全用INT UNSIGNED AUTO_INCREMENT。当时觉得稳妥：小站日活三千，撑死十年不溢出。结果二二年客户打电话，说后台导出卡住三小时——查出来是user_id主键快到21亿了，最后几百万ID插入直接报错。我原以为INT能扛住流量增长，结果它连站长自己养出来的用户池都兜不住。那天挂掉电话，我翻了下文档，MySQL早支持BIGINT了，一三年就有，只是我们那会儿看社区帖都说“INT省空间”，没人提“用户数破亿后你靠什么续命”。错就错在这儿：把省那4个字节，当成了长期设计的全部逻辑。

　　二二年帮一个做医疗科普的站长重构数据库。他后台全是“采集+伪原创”，每篇文章带27个字段：source_url、crawl_time、rewrite_score、fake_keywords……我一眼扫过去就说：“别建这么多冗余字段。”他眨眨眼：“老师，以前不是都这么干？”我说是啊，一三年老陈就在我旁边敲CREATE TABLE articles (id INT, title VARCHAR(255), content TEXT, tag1 VARCHAR(50), tag2 VARCHAR(50)……) ——他写完还笑：“打标签，得留位置。”现在再看，tag字段早该拆成article_tags关联表；content也不该TEXT硬塞，该上JSON类型存结构化段落。但问题是：一七年我明明见过同事用MySQL 5.7 JSON字段解析FAQ列表，我却没推——因为当时觉得“站长又不懂JSON_PATH语法”，怕教不会。现在想想，那是我亲手给劣质设计续了命。优胜劣汰？淘汰的从来不是技术，是人不肯松手的旧习惯。

　　前两天刷到老吴朋友圈，他早不干站了，现在做AI客服中间件。底下有人评论：“当年你做的采集站，现在爬虫全被风控干趴了。”他回了个笑哭表情，没解释。我盯着看了两分钟，想起一三年他蹲机房拔网线的事：服务器IP被封，他就拿个二手路由器插在机柜旁，拨号换IP，烟灰缸里堆满烟头，烟灰簌簌掉进键盘缝隙。后来他问我：“数据库要不要也学路由器，插拔式换架构？”我没接话。其实心里知道，数据库不是路由器——拔错了，整站索引全崩。可当时真没想那么深。

文章配图，仅供参考

　　最近一次碰MySQL是二五年五月，给客户查一条慢查：WHERE status IN ('pending','processing','failed') AND updated_at > '2025-04-01'。explain一看，type: ALL。我说加个联合索引。客户发来截图：索引早就建了，名字叫idx_status_updated。我盯了十秒，才想起来——他建的是(status,updated_at)，但查询条件里status用了IN，MySQL在5.7之前压根不走这个索引。我原以为新版本自动适配，结果发现他们没升版本。停顿了一下，我打字说：“把索引改成(updated_at,status)，倒过来。”手指悬在回车键上，没发出去。现在这套我也拿不准还能干几年。

（编辑：均轻资讯网）

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