评审表结构的时候，十份设计里能看到八份带着reserve1、reserve2、extra之类的预留字段，问一句预留来干嘛，答曰「以后加需求不用改表，老经验了」。数据库设计里这个「老经验」，如今争议其实很大，值得掰开讲讲。
预留字段的三个真实代价
第一，没法用。预留字段没有索引、没有类型约束、没有注释，真到用的时候你会发现，它存不了金额也建不了索引，最后还是得老老实实改表。第二，污染代码。字段名叫reserve1，半年后没人记得里面存的是什么，新同事只能翻历史数据猜，猜错了就是事故。第三，掩盖设计懒惰。习惯性甩几个预留字段，往往说明开发者没认真想过业务接下来往哪走，真有明确预期的扩展，应该设计成明确的字段或表，而不是留一个黑洞。
比预留字段靠谱的几种做法
- 有明确预期的，直接按预期设计：知道以后要多规格，现在就把规格子表建出来，哪怕先只支持单规格。
- 属性确实杂且不可预期的，比如商品的各项参数，用JSON类型字段集中存，MySQL 5.7之后支持查询，比散着放预留字段干净得多。
- 变化实在太频繁的模块，考虑拆出独立的扩展表，主表保持稳定，两边互不拖累。
顺手破一个老印象
顺带说一句，现在改表没想象中可怕：MySQL 5.6之后加字段基本是秒级操作，几百万行的表也能在线加。「改表要锁库」这个老印象，还停留在十多年前，别拿它当设计借口。
当然也不是一刀切地反对预留，极少数场景下留一个备用字段可以接受：比如接口报文里明说了下个版本会加某个固定含义的字段，提前建好类型对得上，将来直接启用。判断标准就是你能说出它将来装什么、什么类型。说不出来的预留，一律视为偷懒，评审时直接打回。
两条建议：新项目表结构里不要出现reserve1这种无意义字段，每个字段都要有名字有用途有注释；老项目里的预留字段，趁文档还全的时候赶紧把实际用途补记进数据字典。拿不准数据库设计该怎么留余量的，可以找比格网络把把脉，他们给出的设计一般都附一句「将来怎么扩」，这句话最值钱。
