数据库结构设计：避免后期重构的核心原则

1. 为什么数据库结构会成为后期重构的“重灾区”

技术栈选型之后，紧接着要面对的就是数据库结构设计。很多人会觉得技术栈选型是个大决定，框架、语言、中间件选错了影响很大，但实际上真正让项目后期痛不欲生的，往往是数据库表结构。应用代码出了问题，改起来半天就能搞定；表结构出了问题，涉及的可能是几十张表、几百个接口、几万条历史数据，迁移一次就是一个大工程。我见过太多项目，刚上线半年就开始“机房重构”式的全量迁移，原因无外乎就是初期表结构设计埋了雷。

先明确一个概念：数据库结构重构和代码重构完全是两件事。代码重构，你可以在不改变外部行为的前提下调整内部实现，风险可控。但数据库结构重构，你面对的是线上存量数据，是正在运行的业务，是上下游一堆依赖这张表的服务。改动一个字段类型，可能就要同步改十几个微服务；拆一张大表，可能要写几十个数据迁移脚本。为什么这种风险会在项目初期积累？根本原因在于，数据库结构是“向下兼容”压力最大的那一层，一旦数据写进去了，就很难再回头。

那为什么初期设计这么容易出问题？我自己的经验是，多数情况下不是“设计能力不够”，而是“设计顺序错了”。很多团队技术栈选型做完之后，兴奋地开始写代码，写接口，数据模型是边写边冒出来的。业务跑了两个月，发现订单表和用户表之间的关系一开始就理解错了，于是开启第一轮重构；再过半年，发现业务上需要一个字段，但不知道该加在哪张表，于是开启第二轮重构；等到系统开始做数据分析、做报表，发现事实表和维度表的概念完全没落地，这时候已经不是重构表，而是重构整个数据架构了。

避免这个局面的关键，是在动手写第一行业务代码之前，把数据库结构当成一个“一等公民”来认真设计。不是说要画一整周时间去磨一个完美的ER图，而是至少要有一套清晰的设计原则和一个可执行的建模流程。技术栈选型解决的是“用什么工具做”的问题，数据库结构设计解决的是“数据如何被组织和流转”的问题。后者其实更难，因为它直接决定了以后演进的空间。

这篇文章不是说教，是把我这些年踩过的坑、总结出来的方法、以及一些可以用在项目初期的实用清单整理出来。适合谁看？正在做技术选型后的架构设计、准备建库建表、或者已经感觉到现有表结构撑不住后续迭代的开发者和架构师。也适合那些技术栈选型做完、正要开始数据库设计但不知道从哪下手的团队参考。下面进入正题。

2. 项目初期数据库设计的整体思路拆解

2.1 搞清楚“避免重构”不是“设计一次到位”

我见过很多团队的误区：为了“避免后期重构”，所以要求数据库结构在设计阶段就完美无缺，覆盖所有可能的业务变化。结果就是设计阶段拖了两周，产出几十张表，字段密密麻麻，等真正开始接业务，发现需求理解还是偏了。这是典型的过度设计，比不设计更可怕。

我的观点是：数据库结构设计的目标不是“永不重构”，而是“让重构成本可控”。 换句话说，你要确保的是：

• 常见的、大概率会发生的业务变化，在设计上预留了平滑演进的路径；
• 真正发生重构时，影响面是可以被限定的，而不是牵一发动全身；
• 核心业务数据（用户、订单、资产等）的建模是稳定的，非核心的数据哪怕推倒重来成本也可接受。

这个思路和写代码是一样的。你不会因为某个接口后面可能改逻辑，就给它加几十个配置项；你会做的是保持接口边界清晰、参数尽量稳定、内部实现可以随意替换。数据库结构设计也是一个道理，核心是稳定边界和变更隔离。

那“稳定边界”怎么理解？举个例子，用户和订单的关系，这个在绝大多数业务里都是稳定的。用户下单、订单归属于用户，这个事实不会变。但订单的业务状态，从“待支付”到“已支付”到“已发货”再到“已完成”，这个流程是可能变的。你可能一开始是三步状态机，后来变成五步，甚至加入退款、售后等分支。如果你把状态设计成“用户表里存一个订单状态字段”，那每次状态变化都要改用户表，这就是边界没划好。如果你把状态放到订单表、甚至独立的订单状态流转表里，用户表就不会被这种变化波及。

所以，项目初期的数据库设计，与其说是“设计数据结构”，不如说是“划分数据变动边界”。核心是找到那些变化频繁的维度，把它们的变更限制在局部。

2.2 先做业务建模，再做物理表设计

技术栈选型之后，团队手上往往有一堆现成的ORM框架，比如MyBatis、Hibernate、Prisma，这让建表门槛变得极低。用框架建表，一个实体类对应一张表，字段和属性一一映射，开发效率确实高。但这样做的隐患是，ORM模型和业务模型被混为一谈。

举个我实际遇到的例子。一个做电竞陪玩/护航接单的小程序，初期做技术栈选型，后端选了Node.js + MySQL，ORM用的是Prisma。开发同学写了个 Order 模型，里面放了用户ID、陪玩师ID、游戏名称、段位、单价、订单金额、优惠金额、实付金额、状态、创建时间、支付时间、开始时间、结束时间……看起来没问题，因为订单详情页面就是展示这些字段。但问题出在：后来业务要在订单里增加“护航服务”和“陪玩服务”两种类型，这两种类型的字段差异很大，护航要记录赛季、段位要求，陪玩要记录场次、时长。如果当初只建了一张大订单表，这个时候要么加一堆可空字段，要么拆表。

如果一开始做了业务建模，你会发现“陪玩订单”和“护航订单”虽然都叫订单，但核心业务对象是不同的。它们可能共享一个订单主表（用于统一下单、支付、结算流程），但各自的扩展属性应该放到独立的业务扩展表中。这种设计上的差异，不是ORM模型能帮你识别出来的。

所以我的建议是：跳开ORM，先用业务语言画一遍数据模型。 你可以用传统的方式画ER图，也可以用事件风暴（Event Storming）快速梳理业务流转中的聚合和实体。关键是，设计过程的主体是业务人员 + 后端开发，不是ORM框架。

2.3 数据库选型和表结构设计是耦合的

技术栈选型阶段，你可能已经定了数据库是MySQL还是PostgreSQL，或者是MongoDB、时序数据库等。这里要提醒的是：不同数据库的表结构设计思路差异巨大，不要用MySQL的思路去设计MongoDB的集合结构，更不要用关系型范式去套时序数据库。

比如热搜词里有“时序数据库的数据库结构怎样设计”，这其实是一个典型的“选型后遗症”。很多团队早期图方便，把监控指标、订单趋势、用户行为日志全塞进MySQL，设计出各种event表、log表。等数据量上来了，MySQL扛不住了，才想起来应该用时序数据库。但时序数据库的表结构设计和MySQL完全不同，MySQL里你可能会为每个指标建列，时序数据库里通常是一个metric一行、时间戳 + tag + value的结构。这个改动不是SQL迁移能解决的，而是整个数据写入和查询链路都要重写。

所以“技术栈选型之后做什么”这个系列，数据库结构设计一定要和数据库选型绑定讨论。如果你选的是关系型数据库（MySQL/PostgreSQL），范式化和索引设计就是重点；如果是文档型（MongoDB），嵌套文档的边界设计就是重点；如果是时序库（InfluxDB/TDengine），数据模型设计、tag设计和保留策略就是重点。别拿一套方法论套所有数据库。

3. 避免后期大规模重构的5条核心设计原则

3.1 原则一：核心表结构从“业务事实”出发，不从“页面字段”出发

设计表结构时，最常见的驱动方式是“这个页面需要展示什么”。订单列表页要展示订单号、用户昵称、陪玩师昵称、游戏、金额、状态，于是订单表里就放了这些字段。看起来没毛病，但这不是“业务事实”，只是“一个UI视图”。

从业务事实出发的意思是，你要先回答：订单这个业务对象，它的生命周期是什么？它由哪些不可分割的动作产生？它和用户、陪玩师、游戏、结算单这些对象之间是什么关系？回答了这些问题，你才知道订单表真正的核心字段是什么。

还是用陪玩订单举例。从业务事实出发，订单至少包含以下几部分：

• 订单主体信息：订单号、订单类型、下单用户、接单陪玩师、所属游戏、订单状态、下单时间。这些是订单的核心骨架。
• 履约信息：服务开始时间、结束时间、场次、区服、段位要求。这些是履约相关的业务属性，不同类型订单差异很大。
• 财务信息：单价、数量、原始金额、优惠金额、实付金额、支付流水号。这些应该单独建财务表，别混在订单表里。
• 状态流转信息：每一步状态变化的时间、操作人、原因。这应该是一张独立的订单状态流水表。

如果你把这些都堆在一张大订单表里，初期确实省事，联表都省了。但当业务开始复杂化，支付、结算、售后、对账都要动订单数据时，你会发现大表成了所有后续迭代的瓶颈，因为任何一方的需求变化都会让你改订单表结构。这本质上就是没有做好“变更隔离”。

3.2 原则二：范式化起步，反范式化按需局部引入

关系型数据库设计绕不开范式化。但我的经验是：不要太纠结于第几范式，关键是理解范式化的目的是消除数据冗余和更新异常。 项目初期，我一般建议先按第三范式（3NF）来建模，这样能保证数据的一致性。但完全不考虑查询性能的纯范式化，在业务复杂后一定会被性能问题打脸，到时候你还是得反范式化。

反范式化不是“违背原则”，而是“按需冗余”。比如一个订单列表页需要展示用户昵称和陪玩师昵称，如果严格按范式，你得三表联查。订单量小的时候无所谓，但订单量大了之后，这种高频查询会成为数据库的负担。这时候可以在订单表冗余一个用户昵称字段，它的代价是有更新不一致的风险，但在绝大多数业务里，用户修改昵称的场景很少，且昵称不一致不会造成资损，冗余是可接受的。

这里特别想说一个热搜词“从星形到三角形：永磁同步电机FOC+SVPWM控制的相位偏移与扇区重构”。乍看和数据库没关系，但“从星形到三角形”背后的思路——改变绕组连接方式，牺牲一部分属性，换取更优的运行特性——和数据库的范式化到反范式化异曲同工。你在设计表结构时，也要敢于做“连接方式”的切换：哪些字段应该通过JOIN获取，哪些应该直接冗余存储，这不是拍脑袋，而是根据真实的查询模式和写入频率来决定的。

反范式化的实操建议：一开始严格按范式设计，然后在压测或日常开发中发现热点查询时，再针对性地增加冗余字段或汇总表。别在项目第一天就大面积反范式化，因为你还没搞清真正的查询热点，盲目冗余只会让你提前背上数据一致性的包袱。

3.3 原则三：主键设计别偷懒，全局唯一ID比自增ID抗风险能力强

一提到主键，很多人下意识就是自增ID，这本身没错。小项目、单库单表、没有数据合并需求，自增ID完全够用。但一旦业务增长，你很可能要做分库分表、读写分离、甚至多库同步，这时候自增ID就成了障碍。更麻烦的是，自增ID会暴露业务量，容易被爬虫遍历，这在To C业务里是大忌。

我的建议是：从第一天就用全局唯一ID（比如雪花ID、UUID或者带业务语义的业务单号），不要用自增ID作为对外暴露的主键。

雪花ID的好处是趋势递增、插入性能好、具备时间顺序、能够在分布式环境下不依赖中心节点生成。UUID的问题是无序，作为主键会导致B+树索引频繁分裂，写入性能下降明显，所以我会优先推荐雪花ID。如果你用的是MySQL 8.0以上，也可以考虑用 UUID_TO_BIN 函数把UUID转成二进制存储，缓解无序问题。

但要注意一个细节：对外展示的订单号、用户ID，不要直接用雪花ID裸奔。 雪花ID本身是long型，可以在URL里直接暴露，但如果你的业务有对账、客服、安全风控需求，最好在业务层再做一层业务编号，比如“OD + 日期 + 随机序列”。雪花ID留在数据库里作为物理主键，业务编号作为逻辑主键。这样既保证了数据库层面的性能，又兼顾了业务层面的可读性和安全性。

3.4 原则四：状态和枚举字段用“代码字符串”，不要用数据库枚举类型

MySQL的ENUM类型，看起来很美，定义了一组固定值，存进去的数据自动校验，读出来还有描述。但一旦业务要加一个状态，调整ENUM的定义，就得改表结构。而且ALTER TABLE修改ENUM在数据量大时会有锁表风险，线上变更非常痛苦。类似的问题也出现在“用0/1表示状态，加注释说明”的设计里——短期有效，但新同事接手后只能靠猜。

我更推荐的做法是：状态和枚举字段全部存字符串代码（String Code），在应用层或在独立的码表/字典表里维护它的语义。 例如订单状态存 PENDING_PAYMENT、PAID、IN_SERVICE、COMPLETED、REFUNDING、CLOSED，而不是 0、1、2、3、4、5。好处很多：

• 新增状态不需要改表结构；
• 代码里直接可读，日志排查方便；
• 状态之间可以有映射关系，比如旧的 PAID 和新的 PREPARING 可以在代码层做兼容。

有些人担心字符串字段长度问题，实际上一开始就把这个字段定义成 VARCHAR(32) 或 VARCHAR(64)，索引空间增加可以忽略不计，但换来的可维护性是巨大的。

3.5 原则五：人人都要有的“审计字段”和“扩展字段”

我几乎在每一张业务表里都会预留这几个字段：

• created_at：创建时间（数据库默认值设为当前时间）
• updated_at：最后更新时间（让ORM或数据库自动更新）
• deleted_at：软删除标记（NULL代表未删除，时间代表删除时间）
• version：乐观锁版本号
• creator_id / updater_id：创建人/更新人（方便追溯）

有些开发觉得这是在“过度设计”，尤其是版本号和创建人字段，觉得根本用不上。但真实场景是：一旦线上出问题，客服反馈某条订单数据不对，你要排除是哪个用户干的、哪个时间点变的、是不是并发覆盖，没有这些字段，你只能干瞪眼。到了这个阶段再想补审计字段，成本远高于第一版建表时加上去。

“扩展字段”我建议谨慎使用。业界有一种做法是预留一个 ext JSON字段存扩展属性，这个做法本身很灵活，但滥用会让核心查询无法走索引，也会让数据质量快速恶化。我的经验是：核心查询和核心业务逻辑涉及的字段必须显式建列，扩展字段只用来存低频、非结构化的补充信息。 比如订单表加一个 ext JSON字段，用来存前端页面某些个性化展示需求的数据，可以；但如果你要拿 ext 里的某个值做范围查询、排序、分组，那就必须把它提出来单独建列。如果你选的是MySQL 5.7+，JSON字段可以和虚拟列 + 索引配合使用，但这属于进阶玩法，需要谨慎评估。

4. 实操案例：从业务建模到建表落地全流程

4.1 场景设定与技术栈背景

为了把上面的原则落到可执行的步骤里，我设计一个具体的实操场景。假设我们正在做一个“电竞陪玩/护航接单小程序”，业务目标是把社群里的陪玩接单流程搬到线上。技术栈选型已经完成：前端是微信小程序，后端是 Java Spring Boot + MyBatis-Plus，数据库是 MySQL 8.0，ORM提供自动建表能力但我们决定关闭它、用手写SQL管理表结构，部署在云服务器上。

这里先用 STRICT_TRANS_TABLES，关闭宽松模式，避免写入时数据被截断或静默转换。从业务视角看，核心业务流程是：用户浏览陪玩/护航服务列表 → 选择服务并下单 → 支付 → 陪玩师接单 → 服务履约 → 完成 → 评价 → 售后退款。角色有：普通用户（下单方）、陪玩师（接单方）、管理员（平台运营）。

4.2 第一步：梳理业务实体和关系

建表前先建ER模型。我一般会列一张“业务对象清单”，把核心名词都列出来，然后标注它们之间的关系。这个阶段不要想字段，不要想类型，只用业务语言描述。

核心实体有：

• User（用户）：既包含普通用户，也包含陪玩师。陪玩师可以看作是一种有特殊资质和配置的用户。
• Game（游戏）：英雄联盟、王者荣耀等，是服务分类的一个维度。
• ServiceType（服务类型）：陪玩、护航、上分、教学等。每种服务有不同的属性。
• Order（订单）：用户和陪玩师之间的服务契约。
• Payment（支付流水）：与订单关联的支付详情。
• Settlement（结算单）：平台和陪玩师之间的结算记录。
• Review（评价）：用户对服务的反馈。
• FundAccount / Wallet（钱包）：陪玩师的余额，用于提现。

实体关系：

• 一个 User 可以是普通用户，也可以申请成为陪玩师，所以陪玩师的信息应该从 User 扩展出来，而不是另起一张独立用户表。这里我选择建一张 t_user_profiles 或 t_booster_info 来存陪玩师的额外信息，和 t_user 是一对一关系。
• 一个 Order 属于一个 User（下单方）和一个 User（接单方/陪玩师）。
• 一个 Order 可以关联一条或多条 Payment 记录（比如一笔主支付、一笔退款）。
• 一个 ServiceType 和 Game 是多对多关系，因为一个游戏可以有多种服务类型，一种服务类型也可以横跨多个游戏。所以需要一张关联表 t_game_service_type。
• 一个 Order 对应一个 ServiceType 和 Game 的快照，注意这里要存“快照”，而不是直接关联表ID。因为游戏或服务类型的名称、价格可能在日后调整，但订单产生那一刻的信息不能被改变。

4.3 第二步：核心表SQL落地

基于ER模型，我来写几张核心表的建表SQL。直接贴关键的，后面再补充说明设计意图。

sql复制-- 用户主表
CREATE TABLE t_user (
  id BIGINT NOT NULL COMMENT '物理主键雪花ID',
  user_no VARCHAR(32) NOT NULL COMMENT '业务逻辑用户编号',
  phone VARCHAR(20) NOT NULL COMMENT '手机号',
  nickname VARCHAR(64) NULL COMMENT '用户昵称',
  avatar_url VARCHAR(512) NULL COMMENT '头像地址',
  user_type TINYINT NOT NULL DEFAULT 0 COMMENT '用户类型：0-普通用户，1-陪玩师，2-平台管理员',
  status VARCHAR(32) NOT NULL DEFAULT 'ACTIVE' COMMENT '用户状态：ACTIVE/DISABLED/FROZEN',
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  deleted_at DATETIME NULL COMMENT '删除时间，NULL代表未删除',
  version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
  PRIMARY KEY (id),
  UNIQUE KEY uk_phone (phone),
  UNIQUE KEY uk_user_no (user_no)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户主表';

注意几个点：

• user_no 是业务编号，暴露给前端的、客服查询用的、日志打印的都应该是它，物理主键 id 只在系统内部JOIN用，不暴露。
• phone 做了唯一约束，这是用户登录的核心凭证。但要注意，如果未来业务流程变化，一个手机号可能对应多个子账号，这种唯一约束就会成为制约。所以在初期要和产品确认清楚。我这次场景假设一个手机号只能注册一个账号，如果业务上有“主副账号”的诉求，就不要把 phone 设为唯一键。
• user_type 用了 TINYINT 而不是 VARCHAR 字符串，这是当前原则的一个例外。原因是在我的设计语境里，用户类型这个枚举非常稳定，而且参与大量索引和权限判断，用TINYINT能够有效缩小索引空间。但如果团队觉得可读性优先，也可以换成 VARCHAR。这里要说明的是，设计原则不是教条，核心是团队内部约定一致。
• version 是乐观锁，MyBatis-Plus支持得比较好，更新时自动带条件 WHERE version = #{oldVersion}，防止并发覆盖。

接下来是订单表。这是核心中的核心，我会把订单主表拆得比较克制，扩展属性放到扩展表：

sql复制CREATE TABLE t_order (
  id BIGINT NOT NULL COMMENT '物理主键雪花ID',
  order_no VARCHAR(32) NOT NULL COMMENT '业务订单号，格式OD+日期+随机序列',
  user_id BIGINT NOT NULL COMMENT '下单用户ID（t_user.id）',
  booster_id BIGINT NOT NULL COMMENT '接单陪玩师用户ID',
  game_id BIGINT NOT NULL COMMENT '游戏ID（t_game.id）',
  game_name VARCHAR(64) NOT NULL COMMENT '游戏名称快照',
  service_type_id BIGINT NOT NULL COMMENT '服务类型ID（t_service_type.id）',
  service_type_name VARCHAR(64) NOT NULL COMMENT '服务类型名称快照',
  unit_price DECIMAL(10,2) NOT NULL COMMENT '单价',
  quantity INT NOT NULL DEFAULT 1 COMMENT '数量/场次',
  total_amount DECIMAL(10,2) NOT NULL COMMENT '原始总金额 = 单价*数量',
  discount_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '优惠金额',
  pay_amount DECIMAL(10,2) NOT NULL COMMENT '实付金额',
  order_status VARCHAR(32) NOT NULL DEFAULT 'PENDING_PAYMENT' COMMENT '订单状态：PENDING_PAYMENT/PAID/IN_SERVICE/COMPLETED/REFUNDING/CLOSED',
  pay_channel VARCHAR(32) NULL COMMENT '支付渠道：WECHAT_PAY/ALIPAY',
  pay_no VARCHAR(64) NULL COMMENT '第三方支付流水号',
  paid_at DATETIME NULL COMMENT '支付成功时间',
  service_start_at DATETIME NULL COMMENT '服务开始时间',
  service_end_at DATETIME NULL COMMENT '服务结束时间',
  ext JSON NULL COMMENT '扩展字段，用于低频非结构化属性',
  remark VARCHAR(512) NULL COMMENT '用户备注',
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  deleted_at DATETIME NULL COMMENT '删除时间',
  version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
  PRIMARY KEY (id),
  UNIQUE KEY uk_order_no (order_no),
  KEY idx_user_id_status (user_id, order_status),
  KEY idx_booster_id_status (booster_id, order_status),
  KEY idx_game_id (game_id),
  KEY idx_created_at (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='订单主表';

订单表里有几个设计决策值得细说：

• 把 game_name 和 service_type_name 做了冗余快照。原因是游戏名称和服务类型名称属于低频变更信息，如果只存ID，订单列表页每次都要JOIN两张配置表。快照保证了历史订单展示的信息永远和下单时一致，即使未来游戏改名叫“英雄联盟2”，老订单照样显示旧名字。这就是“从业务事实出发”而不是“从范式出发”的典型例子。
• 关于 order_status，用了VARCHAR字符串，且状态流转不是简单地在代码里写if-else，而是建议独立做一个订单状态机。这个字段初始就留了32位长度，以后增加新状态不用改表。
• pay_no 和 paid_at 放在了订单表里。严格来说它属于支付信息，但我这里的取舍是：一个订单目前对应一次主支付，不需要单独拆支付表。如果后面出现“一个订单分多次支付”（比如定金+尾款），那就必须拆分支付记录表。前期这样设计，业务上够用，且查询方便。
• 索引设计上，特别注意了 user_id + order_status 联合索引，这是订单列表页最核心的查询模式：用户查看自己的订单，且按状态过滤。单独给 game_id 建索引，是因为运营后台要按游戏筛选订单。给 created_at 建索引，是给时间范围统计用的。千万不要为了“所有可能的查询”都建索引，那是浪费空间还会拖慢写入。

4.4 第三步：处理“继承”和“扩展”场景

陪玩师和普通用户的关系，核心表设计是一个 t_user 表加一张 t_booster_info 扩展表。陪玩师的专属信息（擅长英雄、段位、自我介绍、服务费率、接单状态）放扩展表。为什么不用一张表加一堆可空字段？因为普通用户占绝大多数，这些陪玩师专属字段在普通用户身上全是NULL，既浪费空间又会让表显得臃肿。更重要的是，当陪玩师功能迭代时（比如新增“语音陪玩”资质字段），只需要改 t_booster_info 表，不会影响 t_user 表。

sql复制CREATE TABLE t_booster_info (
  id BIGINT NOT NULL COMMENT '物理主键雪花ID',
  user_id BIGINT NOT NULL COMMENT '用户ID，与t_user.id一对一',
  real_name VARCHAR(32) NULL COMMENT '真实姓名（用于实名认证）',
  id_card_no VARCHAR(64) NULL COMMENT '身份证号（加密存储）',
  id_card_encrypted TINYINT NOT NULL DEFAULT 0 COMMENT '是否已加密',
  game_rank VARCHAR(32) NULL COMMENT '游戏段位，如DIAMOND/MASTER',
  good_at_heroes VARCHAR(256) NULL COMMENT '擅长英雄，逗号分隔',
  intro VARCHAR(1024) NULL COMMENT '自我介绍',
  service_fee_rate DECIMAL(5,4) NOT NULL DEFAULT 0.1000 COMMENT '平台抽成比例',
  boost_status VARCHAR(32) NOT NULL DEFAULT 'OFFLINE' COMMENT '接单状态：ONLINE/OFFLINE/BUSY',
  audit_status VARCHAR(32) NOT NULL DEFAULT 'PENDING' COMMENT '入驻审核状态：PENDING/APPROVED/REJECTED',
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  deleted_at DATETIME NULL,
  version INT NOT NULL DEFAULT 0,
  PRIMARY KEY (id),
  UNIQUE KEY uk_user_id (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='陪玩师扩展信息表';

这里有个细节：id_card_no 在数据库里要加密存储，不能明文。这个字段设计的关键不是SQL本身，而是团队要有统一的字段加密方案。我建议初期就约定好哪些字段属于敏感字段（身份证、手机号、银行卡号），统一走加密服务，不要在业务代码里随意处理。这个问题和数据库结构设计强相关，因为一旦明文数据上线了，事后做数据加密迁移的代价非常大。

4.5 第四步：使用迁移工具管理表结构，而不是靠ORM自动建表

我在前面提到关掉ORM的自动建表能力，这里补充一下原因。ORM自动建表在本地开发很方便，但一旦到了多环境（开发、测试、预发布、生产），每个环境的表都需要有版本管理。自动建表没法回答这些问题：“当前生产环境跑的是哪个版本的schema？”“这个字段是什么时候加上的？”“这条数据迁移脚本有没有在stage环境执行过？”

我的建议是从项目第一天就使用数据库迁移工具。Java技术栈可以选 Flyway 或 Liquibase，Node.js 技术栈可以选 Knex.js 的 migrations 或 Prisma Migrate，Python 技术栈可以用 Alembic。核心思想都一样：把每次表结构变更写成一个版本化脚本，按顺序执行，所有环境保持一致。

我用的是 Flyway，目录结构大概长这样：

code复制db/migration/
  V1__init_schema.sql
  V2__add_order_ext_fields.sql
  V3__create_settlement_table.sql

每个版本脚本只能追加，不能修改历史。应用启动时 Flyway 会检查当前数据库的schema版本，自动执行未执行过的脚本。这样有一个巨大的好处：新同事拉代码后，一条命令就能把本地数据库结构建到最新版本；生产环境上线时，execute顺序是可控的。

在项目初期就把迁移工具用起来，是“避免后期大规模重构”的核心基础设施。因为有了版本化迁移能力，你才敢做小步快跑的迭代式表结构演进，而不是压着一个“最终完美schema”憋大招。小步迭代 + 版本管理，才是数据库设计面对业务变化的正确姿态。

5. 常见问题速查与排查思路

5.1 建表时容易踩的典型坑

我整理了一个表格，把建表阶段最常见的问题和对应解决方案写清楚。这些坑基本都是我或者我朋友的项目里真实遇到过的。

每一行都是我真实见过的。金额用FLOAT 这个坑出现率最高，很多人觉得差别只有几分钱，但在高频交易场景里，浮点误差累积起来就是对账事故。举个例子，假设平台有10万笔订单，每笔1.1元，用户看到的应付金额是 11 万整，但如果用FLOAT累加，很可能得到 109999.99999998，到日终对账就会多出一分钱的差异。对账系统可不会因为你是一分钱就放过你。用DECIMAL(10,2)直接从根源解决这个问题。

又比如 deleted_at 字段。做了软删除之后，所有查询都要注意带上 deleted_at IS NULL 条件。我用MyBatis-Plus的时候，它内置了逻辑删除插件，会自动拼接条件。但如果你用一个不支持逻辑删除的框架，就得靠团队在代码规范里强制统一。否则一旦有一条已删除数据出现在统计结果里，数据报表就会出现诡异偏差。

5.2 线上运行中发现表结构怎么办

即使做了充分的事前设计，线上也难免会出现要调整表结构的时候。绝大多数情况下，问题出现在以下三类：

• 字段长度不够（比如昵称最大64字符，用户填了70个字符，插入被截断甚至报错）；
• 索引没设计好（某个查询特别慢，explain一看走了全表扫描）；
• 新增业务字段（订单要增加一个新属性）。

处理这些问题的核心是：不要直接对线上大表执行ALTER TABLE。 在数据量小的时候（比如百万级以下），执行ALTER TABLE问题不大；但数据量上了千万级，直接ALTER TABLE会长时间锁表，导致线上服务不可用。正确的姿势是：

• 如果是加字段，按“先加字段（设为可空）、再发布代码、再回填数据”的顺序操作；
• 如果是加索引，考虑使用在线DDL（如MySQL的Online DDL）或者在低峰期操作；
• 如果是修改字段类型，一定要先备份相关列数据，做好回滚预案。

另外要注意：即使有迁移工具，也不要让应用启动时自动执行迁移脚本。 在开发环境可以，但在生产环境，我强烈建议把迁移脚本提交到CI/CD流程中，由一个专门的发布步骤来执行，并且执行前要有备份。原因很简单：生产环境跑一堆自动迁移，一旦中途失败，你连现场都来不及抢救。

5.3 哪些“重构”实际上是不可避免的，如何提前预判

说了这么多“避免重构”，我必须诚实地说一句：有一些重构是业务发展过程中必定会遇到的，好的前期设计只能推迟它、缩小它的影响面，但不能消除它。 你要做的不是恐惧重构，而是把那些“注定要发生”的重构尽量延后到业务成熟期，同时让重构成本可控。

两种典型的大规模重构场景：

• 数据量级跨越：从百万级走到亿级。这时候即使你的表结构设计得再好，也必须面临分库分表、引入搜索引擎、数据归档等问题。这是增长带来的必然重构。提前能做的，是确保核心表的主键是分布式友好的，外键约束不要建立在数据库层面，业务代码里不要写死单库单表的逻辑。
• 数据库选型变更：比如从MySQL迁移到PostgreSQL、从关系型迁移到时序数据库。这种重构一旦发生，范围是整个数据链路。但要承认的是，很多选型变更本质上不是技术选型错，而是业务演进超出了预期。比如监控系统早期用MySQL存指标，后来量太大不得不迁移到时序库。

我在设计的时候，会刻意地做一个“数据生命周期规划”，对每张表问一个问题：这个表的数据是冷数据还是热数据？预计能涨到多大？到那个规模时我会怎么做？ 如果一张表我预测它会超过千万行，我可能在初期就规划好按时间分表的方案；如果一张表是配置类数据，我会让它走缓存，减少数据库压力。这个“预判”能力是区分资深工程师和新手的关键。新手看到的是“现在的数据量”，资深看到的是“技术栈选型之后的一年、三年里，这张表会变成什么样子”。

6. 说点实在的：项目初期应该怎么做才不容易返工

最后再分享一些我自己的操作习惯，这些都是我在不同体量的项目上验证过的、能显著降低返工概率的做法。

第一，在建表之前，先写一份一页纸的数据字典。 不要求完整，但一定要把每个核心实体的定义、主要属性、实体之间的关系写清楚。这份数据字典是给团队所有人看的，不仅是后端，还有前端、产品、测试。前端看了知道接口返回的字段背后代表什么业务含义；产品看了知道数据结构对需求的支撑边界在哪；测试看了知道哪些字段是必填、哪些枚举是关键路径。写数据字典的过程，本质上是逼自己想清楚的过程。

第二，不要过早优化索引。 我见过不少开发，在建表第一天就给所有字段都建了索引，理由是“以后查询都用得上”。结果写入速度下降，索引占空间，而且很多索引根本不会命中。正确做法是：核心查询路径上的字段（用户ID、订单状态、创建时间）建立索引，其他索引等到真正出现慢查询时再按需补充。索引的建立是有数学逻辑的，同一个字段如果已经在联合索引里，就没必要再单独建一个单列索引；区分度很低的字段（比如性别、状态只有两三个值）单独建索引性价比很低。

第三，数据库结构评审要纳入技术栈选型后的固定流程。 技术栈选型是架构决策，数据库表结构其实也是架构决策，需要评审。团队里不管是资深的人还是初级的人，都可以参与评审，因为不同视角能发现不同问题。资深的人关注“这样设计未来能不能演进”，初级的人关注“这样设计CRUD好不好写”，业务方关注“这样设计需求能不能落地”。三个视角合在一起，遗漏会大大减少。

第四，利用同步工具定期核查。 热搜词里有个“DataGrip如何同步数据库表结构”，这个操作很有用。多环境之间表结构容易漂移，开发环境加了字段忘了同步到测试环境，测试环境改了个字段类型没通知生产，这种问题很常见。用DataGrip这样的工具做周期性结构对比，能及时发现漂移。当然更规范的做法是用迁移工具保证所有环境从脚本出发，但工具核查仍然是一道有效的安全网。

第五，设计上敢于“留白”。 一份数据库设计如果看起来“刚刚好”能满足所有已知需求，没有任何冗余和弹性，那大概率会在未来三个月内开始吃紧。我说的留白不是让你把表设计得无比复杂，而是给常见的变化留一些余地：状态字段长度留宽一点、可空字段设定默认值、保留一个JSON扩展字段、核心表中的冗余快照字段提前规划。这些“留白”的成本极低，但几乎每一个都会在关键时刻救你一命。

回到标题那个问题：技术栈选型之后做什么？问题3的答案是：数据库结构设计。它不复杂，不需要掌握高深的分布式理论和数学知识，但它需要认真对待。好的数据库结构设计不会让你永远不重构，但它能让每一次重构都变得小、快、可控。这比追求一个“完美的最终schema”要现实得多，也有效得多。技术栈选型定的是骨架，数据库结构设计定的是血脉，血脉通畅，后面无论怎么长，都不会长歪。