DBA熬夜改表？这本MySQL手册让设计运维一步到位

　　工单系统又弹了条消息，我瞥了一眼，又是“表结构变更申请”——运维小哥昨天刚改完索引，今天又要加字段。我原以为这种破事儿只会发生在老项目里，结果去年十月那回，连新上线的服务都栽了跟头。那天凌晨两点，手机亮了一下，DBA在群里吼：“谁设计的订单表？主键用自增ID就算了，状态字段还搞成tinyint？现在订单量涨了，状态码根本不够用！”

　　我翻了下聊天记录，发现这表是三个月前上线的，当时测试环境跑得挺顺，QPS没细看，反正压测没报错。可上线后没两周，产品突然要加“售后中”“已拒收”这类新状态，DBA硬着头皮改了tinyint的范围——从0到255，本来够用，结果产品又双叒叕要加“部分退款”“全额退款”……最后DBA熬到凌晨三点，直接把字段类型改成smallint，还在群里吐槽：“下次再改，我就让你们自己写DDL！”

　　其实这事儿怪谁？前端说“后端接口没留扩展位”，后端说“产品需求变太快”，产品说“用户反馈必须满足”——最后锅全甩给DBA。但说白了，表结构设计的时候，谁都没想到状态码会超过255个。我原以为“用tinyint存状态”是行业惯例，结果翻了翻那本《MySQL手册》，好家伙，第三章第一节就写着：“状态字段建议用enum或varchar，除非状态数量固定且极少。”我盯着屏幕愣了半天——我们团队用了七年的tinyint，居然是反模式？

　　咖啡凉了，我端起来抿了一口，苦得皱眉。窗外天黑了，工位对面的前端小哥还在敲键盘，键盘声噼里啪啦响得像放鞭炮。我想起上周联调时，他因为字段类型不对，改了三次接口文档——后端返回的是int，前端要的是string，最后他直接在前端转类型，还吐槽：“你们后端就不能统一点？”我当时还怼他：“字段类型是DBA定的，关我屁事。”现在想想，可能真该怼自己。

　　那本手册里还提了个“优胜劣汰”的例子：有个电商团队，早期用tinyint存商品类型，后来品类扩张到五百多种，DBA不得不凌晨停机改表，结果导致订单系统挂了十分钟。后来他们重新设计了表结构，用varchar存类型编码，配合字典表维护，再也没为这事儿熬过夜。我翻到这一页时，运维小哥凑过来看，冷笑一声：“我们要是早看到这例子，昨天就不用改smallint了。”

　　其实手册里大部分内容我都懂——索引怎么建、事务隔离级别选啥、分库分表策略——但以前总觉得这些是“高级玩法”，新项目用不上。结果去年十月那回，状态码超标只是导火索，真正的问题是表结构没预留扩展位。比如用户表，手机号字段当初设成varchar(11)，结果后来要支持国际号码，DBA又得改字段长度；订单表的金额字段用decimal(10,2)，结果大额订单来了，数值溢出，财务系统对不上账……这些破事儿，手册里全提到了，可我们团队没人当回事。

　　手机又亮了一下，是测试群的消息：“新版本压测通过，但订单表查询耗时涨了20%。”我点开一看，原来是DBA为了支持新状态，加了个联合索引，结果影响了查询性能。运维小哥在群里骂：“谁让你们加索引的？没看过手册吗？索引不是越多越好！”我盯着屏幕，突然想起手册里那句“索引是空间换时间，但换错了地方，就是双输”——当时觉得是废话，现在才懂，这他妈是真理。

　　其实最让我后怕的，不是状态码超标，而是我们团队对表结构设计的态度——总觉得“现在够用就行，以后再说”。可“以后”从来不会等你准备好。去年十月那回，DBA熬到凌晨改表，第二天早上产品又提了个新需求，说要加“预售”状态。DBA盯着屏幕，沉默了五秒，说：“你们先写需求文档，我去抽根烟。”我知道他在想什么——改表可以，但下次能不能别在我睡觉的时候改？

　　现在那本手册就放在我工位上，翻得最烂的是第三章和第五章——第三章讲字段类型选择，第五章讲索引优化。运维小哥偶尔会凑过来看两眼，然后吐槽：“早看这书，我也不用熬夜了。”前端小哥路过时，会瞥一眼封面，说：“这书名挺土的，但内容好像挺实用。”我笑了笑，没说话——实用不实用，得看用的人愿不愿意改。就像我们团队，去年十月之前，谁都不信“表结构设计能决定运维效率”，现在信了，可已经熬过好几个夜了。

文章配图，仅供参考

（编辑：站长网）

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