工程师建表

工程师建表，工程这事儿听起来像写代码，师建其实更像是工程在搭积木。真正的师建建表不是敲几行CREATE TABLE就完事，而是工程把业务逻辑、数据流向、师建甚至未来三五年可能踩的工程坑，全部压缩进一张二维表格里。师建 我见过最狠的工程建表，是师建在一家物流公司。当时要设计一个订单分表，工程业务方拍着胸脯说“日单量撑死五万”。师建架构师老周没信这个邪，工程他蹲在仓库看了三天拣货流程，师建回来把订单表拆成了主表加扩展表，工程还硬塞了个version字段。三个月后双十一，日单量冲到八十万，那张表愣是没垮。老周后来喝酒时说：“建表不是画格子，是画地图——你得知道哪儿有沼泽，哪儿会塌方。” 建表的第一步永远是问“为什么”，而不是“怎么建”。我见过太多新手上来就设计字段，把客户名称设成varchar(50)，结果遇到一个德国公司全名带后缀，直接截断。真正该做的是先想清楚：这张表要回答什么问题？是“谁买了什么”，还是“哪个仓库发错货”？问题定义错了，表结构再漂亮也是空中楼阁。 字段命名这关，最能看出工程师的洁癖程度。有人喜欢用a1、b2这种缩写，美其名曰“简洁”，等三个月后自己都看不懂。我习惯用业务语言命名——order_status比status强，customer_phone比phone强，因为后者在联表时根本不知道是谁的phone。命名不是给数据库看的，是给下个月那个凌晨三点被叫起来修bug的你看的。 索引这事儿，最容易被低估。很多人建完表就撒手不管，等查询慢成蜗牛才回来补索引。但索引不是创可贴，是地基——你在地基阶段没留好位置，后面想加就得出大事。我有个同事，给一张千万级用户表加了七个索引，结果每次写入都要更新索引树，写入性能直接腰斩。后来删掉三个冗余索引，速度才回来。建表时多想想“这列会被怎么查”，比事后优化强一万倍。 最要命的坑，是预留字段。有人喜欢留一堆col1、col2备用，觉得这样灵活。可实际上，这些字段永远没人用，还占着存储空间，查数据时拖慢速度。真要扩展，用ALTER TABLE加列，一分钟的事，何必让一堆死字段占着茅坑？ 建表做到最后，其实是在做减法。能用一个整数类型解决的，就别用字符串；能用时间戳的，别用datetime；能拆成两张表的，别硬塞进一张。数据冗余不是罪，但无脑冗余是。我记得有次设计订单明细表，业务方非要加个“商品快照”字段，存商品名称和价格。我当时觉得多余，后来商品改价了，历史订单全得靠这个快照还原——那一刻我才明白，建表时多问一句“这数据会不会变”，比什么都重要。 说到底，建表是门手艺活。没有银弹，没有万能模板，只有对业务的理解和对数据的敬畏。你建的每一张表，都会在未来的某个深夜，用查询速度或者数据错乱来回报你。所以，别急着敲键盘，先泡杯茶，把业务方拉过来聊透，再动手。表建好了，后面十年都省心；建砸了，后面十年都在填坑。