用 AI 做数据库设计评审：索引与范式取舍

评审会上，建表语句投在屏幕上，五个人看了十分钟，没人说话。半年后这张表有了八千万行，加一个索引要停服四十分钟，改一个字段类型要写迁移脚本跑一整夜。数据库设计的成本曲线很陡：设计时多花两小时，能省掉上线后的两周。AI 适合做这轮评审的第一遍扫描，它不会漏看字段类型，也不会嫌建表语句长。

评审要看的不是语法，是半年后的查询

建表语句本身很少出错，语法检查器就能过。真正的问题藏在语义里：这个字段允许为空，业务上是不是真的允许；这个组合加了唯一索引，会不会和软删除打架；这个长度是按什么定的，会不会第三个月就装不下。

评审的视角要往前推半年：最常用的五个查询长什么样、数据量会涨到多少、哪些字段会被用来排序和范围筛选。这些问题在建表那天没人问，上线后每天都有人问。

五步走完，从建表语句到迁移预案

五步的产出物性质不同，前三步是找问题，后两步是定方案：

字段和约束这两步是确定性工作，AI 做得又快又全，价值在不漏项。第三步开始需要你提供信息：不说清楚查什么，它给的索引建议就是猜的。第五步最容易被跳过，而它恰恰是上线后最疼的地方——数据量从十万涨到一亿，同一个设计的好坏会翻转。

字段类型和空值，坑都在不起眼处

金额别用浮点。二进制浮点存不下 0.1，累加之后出现分位误差，对账时查半天。用整数存最小单位，或者用定点类型。时间要带时区，跨地区部署时本地时间会成为灾难，存 UTC、展示时再转。

空值是最容易被放过的一项。数据库里的 NULL 表示「未知」，它在比较和聚合里的行为与空字符串、与 0 都不同：NULL 参与的比较结果是未知，计数会跳过它，NOT IN 遇到 NULL 会让整个条件失效。业务上的「不知道」和「不适用」如果都塞进 NULL，后面所有统计都要加特判。宁可在设计时多一个状态字段。

字符串长度也别随手写一个大数。长度影响存储和索引大小，更重要的是它是一份隐含的业务约束——写 20 就是告诉后来的人，这里最多二十个字。

范式还是冗余，看读写比和一致性要求

三范式的好处是改一处就够，不会出现同一事实存三份、三份不一致。代价是查询要多次关联，表一多，一个列表页要连五张表，响应时间就上去了。反范式把常用字段冗余过去，读变快，写要确保多处同步。

判断依据是两个比例：读写比，和一致性容忍度。写多读少、一致性要求高的场景（账务、库存扣减）偏范式；读多写少、允许短暂不一致的场景（商品列表、内容页）可以冗余。中间地带看查询频率，一个每天跑十万次的查询值得为它冗余一个字段，一个月跑一次的报表不值得。

冗余要写清同步责任：由应用层双写、由触发器、还是由定时任务补偿。三种方式的一致性窗口不同，出问题时排查路径也不同。没写清责任的冗余，半年后一定出现对不上的数据。

索引建议里有一半不能照做

模型给的索引清单通常很全：每个筛选字段一个、每个排序字段一个、每个关联键一个。照做之后写入会明显变慢，因为每个索引都要维护。更糟的是重复索引，(a) 和 (a,b) 同时存在时，前者基本多余，最左前缀已经覆盖。

它也不知道你的数据分布。一个只有两种取值的字段，建了索引也走不上；一个九成都是同一个值的状态字段，单独建索引没意义，放在组合索引的后面才有用。这些要靠统计信息和执行计划判断，不靠语义猜测。

大表加索引还有工程约束：是否支持在线变更、会不会锁表、主从延迟会不会被拉长。这些信息不在建表语句里，需要你把数据库版本、数据量、业务低峰期一起交代。评审时把约束写全，提示词里该给的上下文直接决定建议的可用度。它也可能编出不存在的语法或参数，幻觉在技术问答里的表现很典型：语法看着对，跑起来报错。

什么时候该考虑另一种存储

关系库不是唯一选项。写入吞吐极高、只按时间范围查的日志类数据，列式存储更合适；需要按语义相似度检索的场景，向量库更合适，向量数据库的适用边界讲得比较清楚。判断标准不是新不新，是查询形态：按主键和条件精确查，关系库仍然是最省心的选择。

混用的代价要提前算：两套存储之间怎么对齐、出问题怎么回滚、团队会不会维护。多引入一个组件，运维复杂度不是加一，是乘。

速查：设计评审的五条硬规矩

• 金额用整数存最小单位，时间存 UTC
• 空值语义先定清楚，「不知道」和「不适用」分开
• 五个高频查询先写出来，再谈索引
• 冗余字段要写清同步责任和一致性窗口
• 迁移脚本必须在大数据量上试跑一次