站长必避的MySQL设计陷阱：3个致崩关键错误

　　我原以为加个索引就完事了，结果昨晚查慢查询日志看到那条`SELECT FROM user_posts WHERE user_id = ? ORDER BY created_at DESC LIMIT 20`跑了3.7秒——你猜它走了几行？127万。不是1270，是127万。

　　桌上那只干了的马克杯还斜在键盘右边，底下压着张被咖啡渍晕开的打印稿，第九版——就是昨天下午三点十七分发出去、三分钟后前端小陈在钉钉窗口里打了个“？”然后撤回、改发“这个字段渲染不了”的那一版。她刚把状态栏里的loading图标从12帧改到18帧，我这边MySQL在查`user_posts`表，查得比她切图命名还乱：`post_img_v2_final_v3_bak@2x.png`，那个`@2x`还在文件名里飘着，跟没加索引的`created_at`一样，纯属摆设。

文章配图，仅供参考

　　色板里那个说不清的灰，RGB是123,123,125，调色盘上标着“深灰-中性-正文辅助色”，其实谁也没敢问它到底算不算“中性”。就像我们也没人问过，那个UUID主键字段，建的是`CHAR(36)`还是`BINARY(16)`——上线前DBA随口说“都行”，结果跑半年发现碎片率78%，OPTIMIZE TABLE一执行，锁表八分钟。首屏白屏时间突然多出七秒，不是前端的问题，是`user_posts`的聚簇索引在重排时把整个二级索引全踹了一遍。

　　第二个崩点：没空态预判。你肯定遇到过那种情况——首页列表数据全靠`LEFT JOIN`仨表凑出来，其中一张`post_category_rel`连个复合索引都没有，字段还是`TEXT`类型存JSON。我原以为前端扛得住loading态过渡，结果用户一刷，`post_category_rel.category_id`上没索引，JOIN一卡，`ORDER BY post.created_at`就掉坑里去了。小陈在旁边刷短视频外放《爱如火》，声音不大，但“爱——如——火——”每断一下，我脑内就跳出一条EXPLAIN的type: ALL。

　　窗台上的绿萝死了半盆，土是硬的，叶子卷边发黄，根还插在那儿，像极了我们线上那个`post_meta`表——字段名`meta_value`，类型`TEXT`，没加FULLTEXT，也不加约束，运营后台随手塞进去个base64图片，三百兆。那天凌晨两点，我蹲在终端里`SHOW PROCESSLIST`，看见十来个线程卡在`Copying to tmp table`，其中七个都是同一句SQL，WHERE里写的还是`meta_value LIKE '%优惠%'`……而我们根本没给`meta_value`建前缀索引，只建了个长度为10的前缀，够查“优惠”吗？不够。它匹配的是“优”，然后扫全表。查完了再过滤剩下俩字。

　　第三个崩点，也是最蠢的那个：大字段和热点字段放在一张表里。`user_posts`里存了`content TEXT`，又存了`view_count INT DEFAULT 0`，还有`is_pinned TINYINT`。每次`UPDATE user_posts SET view_count = view_count + 1 WHERE id = ?`，它都要读整行，包括那个动辄八千字的`content`。MySQL没那么智能，它不会自动给你做列式缓存。去年秋天那会儿，我翻了三遍手册才确认：InnoDB对单行更新，真就是“全行锁+物理重写”，不是你以为的“只锁view_count字段”。数位笔的笔尖刚换过，今天画交互稿时总打滑，我越急越歪，就像我当时在ALTER TABLE语句里写`MODIFY content MEDIUMTEXT`，结果忘了加`ALGORITHM=INPLACE`，一执行，锁表两小时——而前端在群里发截图：“首屏加载时长从1.2s涨到9.4s”，后面跟了个抱头表情，没说话，但意思很明白：你动的哪根筋？

　　显示器有点色偏，蓝显成紫，上次校色仪借给隔壁组修打印机去了，至今没还。就像那个复合索引，我建了`(user_id, status, created_at)`，想着能覆盖三个高频查询，结果上线后才发现，有条SQL是`WHERE status = 'draft' AND created_at > ?`——user_id根本没传！索引完全失效。EXPLAIN出来的key就是NULL。我查了半小时文档，发现“最左前缀原则”那几个字，原来不是装饰用的。

　　所以啊，别信什么“先快速上线再优化”，站长不是开发者，没权限重启服务，没配DBA，甚至不敢删测试库里那三条脏数据。你一个索引漏建，他下个月的广告结算就跑不通；你一个TEXT字段没分离，他后台导出CSV就会超时；你一个UUID主键定下去，他三年后想迁云，光数据清洗就得请外包写脚本洗三个月。优胜劣汰不是玄学，是`mysqld`进程OOM之后，他站在服务器机柜前，看着监控图里那根直线掉下去，再没起来。

　　切图文件夹里的命名乱七八糟，`icon_home_active@3x.png`和`home_icon_on.png`并存，没人敢动。我现在也一样，手边开着三个tab：一个MySQL官方文档页、一个慢查询日志片段、还有一个是小陈刚甩过来的Figma链接，页面右上角标着“v9-final-final-again”。我点了进去，发现她把那个“空态提示语”从“暂无内容”改成了“这里还空着，等你来填”，下面加了个小笔刷图标。挺好看的。但我得先去把`post_category_rel`表加个`(post_id, category_id)`索引——至少今天晚上加完。别的，等我喘口气再说。

（编辑：草根网）

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