把数据库表设计和 schema 交给 AI 之后，我总结了三个它最容易让你上线即翻车的地方

上个月我要给一个新业务搭库，图省事把需求文档丢给 AI，让它直接出表结构和字段类型。前两张表用得还行，第三张一上线就出事了：并发一高，重复的脏数据直接把统计对账打穿。

我把这类"AI 出 schema"的活前后用了四五个项目，总结出三个它最容易让你上线即翻车的地方。先说结论：AI 能出的不是"能跑的表"，是"看起来合理的表"，这两件事差着十万八千里。

坑一：它默认你"数据量很小"，索引和字段类型都按玩具来

AI 给的 schema，十张里有七八张主键用自增 int，时间字段用 datetime，字符串动不动就 varchar(255)。单机小表没问题，可一旦日增量上百万，int 主键会撞天花板，datetime 比 timestamp 多占空间还不带时区，varchar(255) 全字段扫起来慢得离谱。

我现在做法：让 AI 出第一版后，我必手动补三件事——预估三年的数据量定主键类型、给所有"会被 WHERE/ORDER BY"的字段加索引规划、把枚举类字段收成 tinyint 或独立字典表。AI 不替你想规模，得你自己填。

坑二：它把"关联"画得很美，把"一致性"忘得一干二净

AI 特别爱给你画一张漂亮的三范式 ER 图，父子表、中间表一应俱全。可它几乎从不主动加外键约束、不提幂等、不写"同一条记录被并发改该怎么办"。

我踩过最疼的一次：两张表靠应用层代码"自觉"维护关联，结果一个漏写的更新把主表和明细对不上，对账差了几千条，查了半天才定位。后来我硬性要求 AI 在出 schema 时把"外键/唯一约束/并发更新策略"三样至少给出口头方案，哪怕不落地也要写进设计说明，逼自己看见隐患。

坑三：它用"通用最佳实践"掩盖了"你的真实读写比"

最隐蔽的是这个。AI 给的索引和分表建议，往往按"通用 OLTP 模板"来，不会问你这张表是写多读少还是读多写少。结果该缓存的不缓存，该冗余的不冗余。

我现在的习惯是：出 schema 之前，先给 AI 写清楚"这张表每天大概多少写、多少读、峰值长啥样"。读写比不同，表设计天差地别——读多写少该冗余字段减少 join，写多读少该拆表别堆索引。它不开口问，你就主动喂，不然出来的就是一份"哪都能用、哪都不顺手"的表。

我的判断

AI 出 schema 最大的价值是"快出第一版草稿"，不是"替你定稿"。我现在的固定动作：AI 出三版 → 我按数据量、一致性、读写比三把尺子逐个砍 → 上线前再让 AI 当"挑刺的"专门找我设计的漏洞。

这条我建议先收藏——下次让 AI 帮你设计表之前，先把这三个坑对着过一遍，能少几次半夜被告警叫起来。

最后问问你：你们现在设计表还自己画 ER 图、手定字段类型吗，还是已经习惯先让 AI 出一份再改？有没有哪次 AI 出的 schema 上线后翻过车的？