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

　　去年6月份，我蹲在客户机房里改索引，空调坏了，风扇嗡嗡响得像台老拖拉机——就那会儿，他们站长还在朋友圈发“数据库稳如泰山”，底下配图是MySQL进程top输出。我看了眼他那个主键自增ID上套的联合唯一索引，没说话。他递来半杯凉透的美式，杯底沉着两粒没化的糖渣。

文章配图，仅供参考

　　第二个坑：把用户行为日志塞进主业务表里。他那个user_profile表，本来就二十个字段，硬生生加了last_login_ip、last_login_ua、last_login_geo、last_login_referrer、last_login_device_type——五个text。我问为啥不拆，他说：“省一次JOIN。” 可他忘了innodb_page_size是十六K，而单行超八K就得溢出，溢出后每读一次都触发额外IO。那天下午两点零七分，他运维接了个电话，声音压得低但能听清：“对……嗯……又锁表了……你别动SQL，我马上看……” 前脚挂，后脚他助理推门进来，指甲油还没干，举着手机让我看抖音新出的“DBA崩溃表情包合集”，笑得前仰后合。我没笑。她刚出门，我切到show engine innodb status，发现lock_wait_time超过五十七秒，而事务持有者，是他自己写的那个定时清理脚本——它正在update user_profile set last_login_ip = '' where last_login_ip like '192.168.%'，跑了四小时三十八分钟。

　　第三个坑：时间字段用int存UNIX_TIMESTAMP，但WHERE条件写成FROM_UNIXTIME(created_at) > '2023-06-01'。这个我敢打包票，他们开发群里吵过七次，最后一次是前端甩锅给后端，后端甩锅给DBA，DBA把锅甩回给PHP里的date()函数调用方式。其实就一句话：FROM_UNIXTIME()是函数，加不了索引。但没人试过直接改where为created_at > UNIX_TIMESTAMP('2023-06-01')。那天我在他们测试库执行完这条改写，延迟从平均四百一十三毫秒掉到十八秒。站长盯着屏幕看了半分钟，突然转头问我：“那……我们线上是不是也得重跑一次数据迁移？”我摇头。他松了口气。我补了句：“不用迁移，ALTER COLUMN created_at DROP DEFAULT;” 他眨了下眼，手悬在键盘上，停了有七秒。窗外打雷了，但没下雨。后来才想起来——那天下的是阵雨，只是机房没窗户。

　　优胜劣汰是真的。上个月我去另一家救火，他们同样崩，但崩得快、修得狠。DBA凌晨三点在钉钉群贴出执行计划对比图，主键改成bigint后，二级索引B+树层数降了一层。他们技术总监当天就砍掉了所有用JSON字段存结构化配置的接口，理由是：“连explain都看不懂的人，不该碰MySQL”。这话听着刺耳，但你得承认——崩得勤的站点，反而活下来三个；半年才崩一次的，这次崩完就没下次了。因为没人记得它上次啥时候崩的。

　　说到这儿我想起昨天路过咖啡店，玻璃上全是水汽，看不清里面人。服务员擦了三次才把中间一小块擦干净，我瞅见里面坐了个穿灰卫衣的，左手托腮，右手悬在MacBook触控板上方，姿势跟我当年一模一样。他没点单，就在那儿盯着terminal窗口，光标在mysql>后面一闪一闪。我没进去。但记住了他耳机线是深蓝色的，左耳那只掉了漆，露出银色底。

　　对了，他们那个article表，我最后没动索引。只加了覆盖索引(idx_status_content_len, status, content(255), id)，因为content字段前二百五十五字足够支撑高频关键词匹配。至于剩下的四千多字？等他们真哪天要用到全文高亮再说。现在先扛着。反正下个月我就要去帮隔壁直播平台调缓冲池，他们redo log组刚扩容到八个G，据说刷盘速度比前任DBA离婚手续办得还利索。

　　哦，还有件小事——我桌上那盒没吃完的黄焖鸡，冷掉之后酱汁凝成一块深褐色薄壳，扣下来像张微型拓片。我拿指甲刮了两下，纹路挺像B+树叶子节点的分裂示意图。不过我没拍照。这种东西，拍了也没人信。

（编辑：站长网）

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