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

　　去年中秋，服务器在凌晨三点十七分开始吞慢查询，不是报警——是直接失联。我盯着监控看，看着连接数从六百跳到一千八，再被 kill 掉一半，然后重新爬上来。茶水间那台旧咖啡机还在滴水，嗒、嗒、嗒，每一声都卡在 MySQL 的锁等待超时阈值里。

　　微信公众号发这稿子，标题被运营打回来三次，最后一次改得只剩“三个字+一个顿号+崩”，她说“用户刷屏不认逗号”。我原以为是文案问题，结果今天上午重看历史记录，发现第三版标题底下，她手写批注了一句：“要像钉钉消息那样，一眼能喘上气”。我盯着那行字看了十八秒，然后顺手关了编辑器。

　　第一个坑：text 字段当索引字段用，还加 fulltext——不是不用，是你得知道它在什么量级下会自己烧断主从延迟线。我们去年中秋那次，就因为一个评论表的 content 字段建了全文索引，结果每天凌晨两点自动合并碎片的时候，slave 延迟拉到两小时二十七分。我敢打包票：你只要在这字段上加过 order by rand() 或者 like '%关键词%'，它迟早把你拖进死锁风暴眼。那个节点上跑了四个月没报错，第五个月，某天半夜 DBA 在 Slack 里甩了一张堆栈图，截图右下角时间戳是 02:19:03，底下写着“主库 CPU 撑到 97%，但负载平均值只有 1.2”。我说不准这个数字怎么来的，反正他截图前刚被领导六十秒语音训完，语音最后三秒是背景里的打印机卡纸声。

　　凉掉的外卖搁在显示器右侧，铝箔盖掀开了，油凝成一块一块的小琥珀。上面浮着三粒花椒，我没动过。旁边校样纸上印着前天改的 Schema 草图，铅笔写的“users 表加 token 字段→走 UUID → 32 位 hex → 不带短横”，底下用红笔画了个叉，旁边补了句：“又忘了加唯一索引？上次 token 重复导致支付回滚，财务部下午三点催对账。”——这不是我说的，是法务同事上周五下班前扔进共享文件夹的备注文档里抄的。

　　第二个坑：timestamp 默认 CURRENT_TIMESTAMP + ON UPDATE CURRENT_TIMESTAMP，还硬套在大表更新高频列上。我见过最疯的是一个日志聚合表，update_time 改一次，整个二级索引全刷一遍，B+ 树重平衡频率高过我老婆催我修浴室地漏。你别不信，那个表上线三个月后，每次执行 ALTER TABLE ADD COLUMN 都得挑周五晚上九点以后操作——不是为避开流量高峰，是怕触发 online DDL 的 metadata lock 卡死所有 insert。上周三审稿间灯突然闪了七次，空调同时停了二十秒，IT 部门说电路老化，但我查 slow_log 发现第七次闪灯前后各十五秒，刚好是某条 update 的临界窗口。这事我说不准跟电有没有关系，但我能肯定：那个 timestamp 自动更新逻辑，在并发写入冲到三百七十二时，已经不是时间戳，是定时雷管。

文章配图，仅供参考

　　昨天印刷对接电话打来，问封面是否确认终版，我说确认，他让我重复一遍“确认终版”，我说确认。电话挂了。其实我没看过 PDF，但我知道只要说错一个字，整批就得重印。就像某些站长坚信“innodb_buffer_pool_size 调够了就万事大吉”，调够了，可 buffer pool 里全是脏页，redo log 写满三次之后——它不会报警，它只会突然拒绝新事务，像个喝醉的服务员，端着盘子站在走廊中央，一动不动。

　　优胜劣汰这话没错，但它淘汰的从来不是技术，是那些觉得“还能扛”的人。我去年中秋没回家，蹲在IDC机柜前面等 failover 完毕，闻着UPS电池味儿吃最后一口月饼。月饼馅是五仁的，咬到第二口才发现里面有颗完整的杏仁，硌牙。现在看到任何带“自动”俩字的配置项，第一反应不是点确定，是伸手摸键盘上的 Ctrl+C —— 手指悬在那儿，悬了三秒，才落下去。

　　接下来两周，我把所有线上环境的 text 字段索引建法导出成表格，发给DBA群，附言只有一句：“标红的部分，今天下班前给我个不删库的替代方案。”没提原因，也没加表情。群里回得很快，第一条是运维老张发的截图：一张新创建的测试实例监控图，load avg 显示 0.31/0.28/0.25，下面备注：“测过了，开 fulltext+stopword 表，10w 条数据下 like 查询压测稳定。但——”他停了半拍，补了句，“千万别试中文分词器自带的停用词表，里面漏了‘的’和‘了’。”

　　审稿间的灯到现在还一闪一闪的。我懒得报修。

（编辑：站长网）

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