数据库存：架构师避坑版方案：表结构设计的目标、动作与检查点
数据库表结构设计最危险的误区，是把“能把数据存进去”当成设计完成。我曾参与过一类库存系统的表评审：上线初期只有商品、仓库和库存数量三张核心表，查询很快，开发也很顺手；半年后业务增加了预占、释放、退货、调拨和盘点，团队却发现库存数字无法解释，某一笔扣减也无法追溯。最后，真正耗时的不是增加几个字段，而是补历史流水、清洗重复数据、重写扣减逻辑，并在业务不停机的情况下完成迁移。
这篇文章讨论的不是如何写一条简单的 CREATE TABLE，而是架构师在表结构评审时，如何从业务事实出发，确定表的职责、字段的语义、约束的边界、索引的路径，以及未来变更和故障恢复的成本。核心判断只有一句话：好的表结构不是字段齐全，而是能够稳定表达业务事实，同时让错误难以写入、让变化能够追溯、让查询和演进都有路径可走。
我在做表结构评审时，通常不会先看字段类型，而是先检查这张表是否同时回答了五个问题：它描述的业务对象是什么；一行数据代表什么事实；什么数据绝对不能重复或为空；最重要的查询如何完成；业务变化后如何兼容旧数据。
这五个问题对应五个设计目标：业务语义清晰、数据一致性可控、核心访问路径可接受、历史变化可追溯、结构能够持续演进。性能只是其中一个目标，而且通常不是最先要解决的目标。职责混乱的表，即使加上十几个索引，也只是在为错误结构延长寿命。
| 设计目标 | 需要回答的问题 | 常见失败表现 | 评审产物 |
|---|---|---|---|
| 业务语义 | 一行记录究竟代表什么？ | 同一字段在不同场景有不同含义 | 实体、事件、状态关系图 |
| 数据一致性 | 哪些错误必须在写入时被阻止？ | 重复订单、孤儿明细、非法状态 | 主键、唯一键、非空及检查规则 |
| 查询可用 | 核心查询从哪里读、如何过滤和排序？ | 全表扫描、深分页、索引重复 | 查询清单、执行计划、索引方案 |
| 可追溯 | 数据为什么变成现在这样？ | 余额异常却找不到变更来源 | 流水、幂等号、操作来源、版本字段 |
| 可演进 | 新增需求能否分阶段上线？ | 加一个字段就要停机或全链路改造 | 迁移脚本、回填方案、兼容和回滚方案 |
如果一张表只解决了“存储字段”这一件事，它更像是接口对象的镜像，而不是可以长期承载业务的数据库模型。接口字段会随着页面和调用方变化，业务事实却相对稳定。架构师的工作，是把短期变化的展示需求与长期稳定的事实记录分开。
判断表是否设计清楚，我会要求设计者用一句完整的话描述一行数据。例如，“一行代表某个仓库中某个商品在某个时刻的库存变化”描述的是库存流水；“一行代表某个仓库中某个商品当前可用的库存余额”描述的是库存余额。两句话看起来接近，但它们的主键、更新方式、索引和生命周期完全不同。
如果设计者只能说“这是一张库存表，里面有商品编号、仓库编号、数量、状态”，却说不清一行记录是当前值还是历史事件，后面一定会出现更新与追加混用的问题。当前余额应该允许被更新，历史流水原则上应该只追加；把两种记录混在一起，数据既无法快速读取，也无法可靠追溯。
很多开发者喜欢把所有校验放在应用代码中，因为这样写起来快、调试直观。但数据库可能同时被接口服务、定时任务、数据修复脚本、运营后台和其他服务写入。只靠某一个应用入口校验，等于默认所有写入者永远遵守同一套规则。
我的判断是：业务流程可以由应用控制，但数据底线必须尽量由数据库约束或明确的事务机制控制。例如订单号不能重复、同一仓库同一商品只能有一条余额记录、金额不能使用浮点数表达，这些都不应只停留在代码注释中。
以一个典型库存系统为例，初版可能只有以下结构：
CREATE TABLE inventory (
id BIGINT PRIMARY KEY,
product_id BIGINT NOT NULL,
warehouse_id BIGINT NOT NULL,
quantity INT NOT NULL DEFAULT 0,
updated_at TIMESTAMP NOT NULL
);
在只有入库、出库两个动作时，这张表确实能工作。页面查询当前库存只需要按 product_id 和 warehouse_id 查询，扣减时执行一次更新，开发成本低，测试数据也容易构造。
问题在于，quantity 只告诉你“现在是多少”，没有告诉你“为什么是这个数”。当库存从 100 变成 80 时，可能是订单扣减了 20，也可能是盘点修正了 20，还可能是重复消费消息、退款冲正或人工修复造成的。没有流水，数据库只能提供结果，不能提供证据。
库存业务通常不会永远只有简单出入库。随着系统运行，至少会出现预占库存、释放预占、实际扣减、取消订单、退货入库、仓间调拨、盘盈盘亏和批次管理等动作。
这时，设计者常见的做法是在原表上继续增加字段：locked_quantity、available_quantity、in_quantity、out_quantity、source_type、source_id。字段数量增加了，但事实边界没有变清楚，最终一条记录可能同时承担余额、累计统计、业务状态和操作日志四种职责。
我见过最难排查的一类问题，就是“数量对不上但无法定位”。团队往往先用当前余额反推历史，再去翻应用日志，最后发现日志保留周期只有 14 天，而库存异常发生在 40 天前。修复过程不只是补数据，还要判断哪些历史记录可信，哪些记录应该被标记为人工调整。
更稳妥的设计通常是把“当前状态”和“历史事件”拆开。库存余额表负责快速回答当前可用库存是多少，库存流水表负责回答每次变化发生了什么。
CREATE TABLE inventory_balance (
id BIGINT PRIMARY KEY,
product_id BIGINT NOT NULL,
warehouse_id BIGINT NOT NULL,
available_quantity DECIMAL(18, 4) NOT NULL DEFAULT 0,
reserved_quantity DECIMAL(18, 4) NOT NULL DEFAULT 0,
version BIGINT NOT NULL DEFAULT 0,
updated_at TIMESTAMP NOT NULL,
UNIQUE (product_id, warehouse_id)
);
CREATE TABLE inventory_transaction (
id BIGINT PRIMARY KEY,
product_id BIGINT NOT NULL,
warehouse_id BIGINT NOT NULL,
transaction_type VARCHAR(32) NOT NULL,
quantity_change DECIMAL(18, 4) NOT NULL,
source_type VARCHAR(32) NOT NULL,
source_id VARCHAR(64) NOT NULL,
request_id VARCHAR(64) NOT NULL,
operator_id BIGINT,
occurred_at TIMESTAMP NOT NULL,
created_at TIMESTAMP NOT NULL,
UNIQUE (request_id)
);这里的关键不在于表名，而在于职责：余额是可变快照，流水是不可随意覆盖的事实记录。两张表可以在同一事务中更新，也可以在最终一致性架构中通过事件补偿，但必须明确两者之间的同步关系和对账方式。
本篇讨论的是数据库内部的表结构设计，而不是数据分析产品选型或报表搭建。即便某个数据分析工具能够连接数据库、做指标分析，也不能替代订单、库存、账户等核心业务表的建模决策。因此，本文不把九数云作为主案例，而使用库存和订单场景说明表结构如何落地，这样更贴近标题对应的技术决策。
如果后续需要把业务数据库接入某数据分析平台，建议先把业务库设计成可追溯、可解释的事实数据源，再通过数仓、数据集市或语义层提供分析模型。不要为了方便报表，直接在交易表里堆积大量报表字段。
字段多并不意味着信息完整，可能只意味着职责没有拆开。一个字段如果同时表达“订单是否已支付”“支付渠道是否成功”“是否允许发货”，它实际上承载了三个不同维度。任何一个维度变化，都可能迫使其他代码重新解释这个字段。
我通常会把字段按四类标记：稳定事实、当前状态、计算结果、扩展信息。稳定事实如成交单价和下单人，通常应直接保存；当前状态如支付状态，需要明确状态转换；计算结果如订单总额，需要说明是否允许重算；扩展信息如第三方返回内容，可以考虑独立扩展表或 JSON。
判断标准不是“字段能不能用”，而是“字段是否只有一个长期稳定的含义”。如果一个字段的解释依赖调用方、页面或某段历史代码，它就已经是结构性风险。
更新时间只能说明一行记录最后一次被修改，不能说明中间发生过多少次变化。订单状态从待支付变成已支付，再变成已取消，如果只在订单表里覆盖状态，系统无法直接判断取消发生在支付之前还是之后。
对于订单、账户、库存、审批等具有过程性的业务，至少要区分当前快照和过程记录。过程记录不一定要复杂到完整事件溯源，但必须能回答谁、在什么时候、因为什么业务单据、将什么值改成了什么值。
订单号、合同号、员工编号经常具有业务规则，可能包含日期、渠道或门店编码，也可能因为业务合并而发生生成策略调整。数据库主键的职责是稳定标识一行记录，不应过度承担展示、沟通和业务编码职责。
更稳妥的做法，是将内部主键、业务唯一键和展示编号分开。内部主键服务于表关联和存储，业务唯一键防止重复创建，展示编号服务于客服、对账和用户沟通。三者可以相同，但不应该因为“目前看起来相同”就强行绑定。
范式化解决的是重复事实和更新异常。例如订单明细中的商品名称，如果商品改名后历史订单也跟着变化，说明订单缺少交易时刻的商品快照。此时保存成交时的商品名称并不是“违反规范”，而是在保存订单事实。
反范式也不是随意复制字段。复制字段之前需要回答三个问题：它代表的是历史事实还是当前状态；谁负责更新它；它与源字段不一致时以谁为准。如果答不出来，冗余字段大概率会变成脏数据来源。
“单表超过一千万行必须分表”是一句很容易传播、但缺少上下文的经验。真正影响性能的因素包括索引大小、数据访问范围、查询选择性、写入热点、锁竞争、磁盘和内存配置、数据库版本，以及是否存在大范围排序和回表。
在没有执行计划、慢查询样本和数据增长曲线之前直接分表，往往会提前引入跨表查询、路由规则、分页一致性和数据迁移问题。分表不是表结构设计的起点，而是对规模和访问模式做过验证后的工程手段。
索引不是免费资源。每增加一个二级索引，写入时通常都要维护一份额外结构；索引过多还会增加优化器选择成本、磁盘占用和变更时间。更严重的是，错误的索引可能让团队误以为问题已解决。
一次慢查询分析至少要同时看 SQL、参数分布、执行计划、扫描行数、返回行数、排序方式和锁等待。若查询使用了函数、隐式类型转换、前置通配符或深分页，单纯添加索引未必有效。
我建议在写 DDL 之前先做一张四分类清单。对象回答“系统里有什么”；事件回答“发生过什么”；状态回答“现在是什么”；快照回答“在某个业务时刻，相关信息是什么”。这四类数据的更新频率、保存周期和一致性要求不同，不能只按页面模块划分。
| 分类 | 典型例子 | 主要特征 | 常见存储方式 |
|---|---|---|---|
| 业务对象 | 商品、用户、仓库 | 相对稳定，被多个流程引用 | 独立主表 |
| 业务事件 | 下单、支付、出库、退款 | 发生后通常不应被覆盖 | 事件表或流水表 |
| 当前状态 | 订单状态、库存余额 | 为了快速读取而维护最新值 | 状态表或主表快照 |
| 业务快照 | 成交价、收货地址、商品名称 | 保存某一时点的真实业务信息 | 交易主表或明细表冗余字段 |
例如商品当前名称属于商品对象，但订单成交时的商品名称属于订单快照。订单页面展示历史商品名称时，应该优先读取订单明细中的快照，而不是实时关联商品表。否则商品改名、规格调整后，历史订单会被“重新解释”。
粒度是表结构设计中最容易被忽略、却最能决定后续质量的概念。订单主表的一行通常代表一笔订单，订单明细的一行代表订单中的一个商品行，库存流水的一行代表一次库存变更。粒度一旦确定，字段就必须与这个粒度一致。
如果把订单级字段和商品级字段放在同一张表里，订单包含三个商品时，订单金额、收货地址和支付状态会重复三次。重复本身还不是最严重的问题，真正危险的是其中一行被修改而其他两行没有同步，导致同一订单出现多个金额或状态。
成交单价、税率、优惠金额属于交易发生时的事实，不能因为商品表或促销规则后来变化而被重新计算。订单总额则可能是由明细金额、运费和优惠金额计算出的结果。是否保存总额，要看读取频率、计算成本和对账要求，但必须明确保存值的来源与重算规则。
我的经验是：对账相关的金额通常需要保存不可变的业务结果，并保留计算明细；临时列表中的展示字段可以实时计算或通过分析模型生成。交易库不要为了省几个字段，把所有金额都交给查询时动态计算，也不要为了方便，把所有报表指标永久塞入交易表。
可以把规则分为三层。第一层是数据库能直接保证的底线，例如主键非空、业务编号唯一、同一仓库与商品组合不能重复。第二层是需要事务保证的组合动作，例如扣减余额同时写入流水。第三层是需要应用编排的业务流程，例如订单状态是否允许从已发货退回待支付。
不要把所有规则都塞进数据库，也不要把所有规则都留给应用。边界清晰的做法是：数据库负责结构性约束，事务负责原子性，应用负责流程编排，定时任务和对账程序负责发现跨系统或历史数据问题。
建表评审时，我会要求开发者列出至少五类真实访问：按主键查询详情、按业务键查询、按状态和时间查询列表、按关联键查询明细、定时任务扫描待处理数据。没有查询样本时，索引只能算猜测，不应被当作最终方案。
组合索引的顺序也不是“区分度最高的字段永远放第一”。需要结合等值条件、范围条件、排序条件和实际数据分布判断。一个字段区分度高，但如果查询几乎不用它，建立在最左侧也没有价值。
-- 示例：查询某仓库中待处理且按创建时间递增的库存任务 SELECT id, product_id, quantity, created_at FROM inventory_task WHERE warehouse_id = ? AND status = 'PENDING' AND created_at > ? ORDER BY created_at ASC LIMIT 100;
针对这类查询，通常需要验证类似 (warehouse_id, status, created_at) 的组合索引是否能减少扫描范围。但这只是候选方案，最终仍要通过执行计划和不同参数分布验证。若某个仓库占据绝大多数任务，索引选择性可能与平均数据完全不同。
库存扣减最常见的两个错误，一个是重复处理同一业务请求，另一个是并发更新覆盖。前者需要幂等键或业务唯一键，后者需要条件更新、版本号、行锁或其他并发控制方式。仅仅把数量读出来、在应用中减去一部分、再写回数据库，无法自动防止两个请求互相覆盖。
UPDATE inventory_balance SET available_quantity = available_quantity - ?, version = version + 1, updated_at = CURRENT_TIMESTAMP WHERE product_id = ? AND warehouse_id = ? AND available_quantity >= ? AND version = ?;
执行后必须检查影响行数。影响行数为 1，说明条件满足并完成更新；影响行数为 0，则可能是库存不足、版本冲突或记录不存在。这个判断应该成为业务流程的一部分，而不是更新后无条件返回成功。
订单主表适合保存订单编号、下单人、订单状态、支付状态、收货快照、订单金额和时间信息。商品名称、商品规格、成交单价和购买数量属于订单明细，因为它们的粒度是订单中的商品行，而不是订单整体。
CREATE TABLE sales_order (
id BIGINT PRIMARY KEY,
order_no VARCHAR(64) NOT NULL,
customer_id BIGINT NOT NULL,
order_status VARCHAR(32) NOT NULL,
payment_status VARCHAR(32) NOT NULL,
receiver_name VARCHAR(128) NOT NULL,
receiver_phone VARCHAR(32) NOT NULL,
receiver_address VARCHAR(512) NOT NULL,
goods_amount DECIMAL(18, 2) NOT NULL,
discount_amount DECIMAL(18, 2) NOT NULL DEFAULT 0,
shipping_amount DECIMAL(18, 2) NOT NULL DEFAULT 0,
payable_amount DECIMAL(18, 2) NOT NULL,
created_at TIMESTAMP NOT NULL,
updated_at TIMESTAMP NOT NULL,
UNIQUE (order_no)
);
CREATE TABLE sales_order_item (
id BIGINT PRIMARY KEY,
order_id BIGINT NOT NULL,
product_id BIGINT NOT NULL,
product_name_snapshot VARCHAR(256) NOT NULL,
specification_snapshot VARCHAR(512),
unit_price DECIMAL(18, 2) NOT NULL,
quantity DECIMAL(18, 4) NOT NULL,
item_amount DECIMAL(18, 2) NOT NULL,
created_at TIMESTAMP NOT NULL
);
这里保留商品名称快照，并不是为了复制商品表，而是为了保证历史订单语义稳定。订单明细中的成交单价也不应实时读取商品当前售价，否则商品调价后，历史订单金额会失去依据。
order_status 和 payment_status 不应混成一个字段。订单是否已发货与支付是否成功属于不同状态维度，一个订单可能支付成功但尚未发货，也可能支付失败但订单仍处于待支付状态。
| 状态维度 | 示例状态 | 允许变化的判断 | 不建议的做法 |
|---|---|---|---|
| 订单状态 | 待支付、已确认、已发货、已完成、已取消 | 依据订单流程和操作权限判断 | 用一个布尔字段表达全部生命周期 |
| 支付状态 | 未支付、支付中、已支付、已退款 | 依据支付回调和对账结果判断 | 仅依赖前端返回结果修改 |
| 履约状态 | 待分配、拣货中、已出库、配送中 | 依据仓储和物流事件判断 | 与订单状态互相覆盖 |
如果状态变化涉及审计、退款或争议处理，建议增加状态历史表。历史表不只是记录“旧状态”和“新状态”，还要保存变更来源、操作人、关联单据、请求号和发生时间。时间字段至少要区分业务发生时间与系统落库时间，防止异步回调导致排序误判。
库存余额表通常按“商品加仓库”建立唯一性。若业务存在批次、货主、库位或库存状态，这些维度也必须进入唯一键，否则同一商品在不同批次或不同状态下的库存会被错误合并。
库存流水表的数量变化应使用有符号数，入库为正、出库为负，或者使用变化前数量与变化后数量同时记录。两种方式各有取舍：有符号变化便于汇总，前后余额便于审计，但前后余额需要在并发场景下确保记录顺序和事务关系。
如果发现流水错误，优先采用冲正流水或调整流水，而不是直接修改原记录。直接改历史流水会让已经完成的对账结果失去依据，也会导致下游报表在不同时间读取到不同历史。
余额表与流水表不一定在任何时刻都能简单相加，因为系统可能存在期初库存、冻结量、在途库存和盘点调整。但它们必须存在一套明确的对账公式。例如，可用库存可以由期初可用量加上所有已生效变更量，再减去冻结或占用量得到。
对账程序的价值不在于把错误自动改掉，而在于尽早发现错误并保留修复证据。自动修复如果没有告警、审批和修复单据，可能只是把一个难发现的问题变成另一个更难发现的问题。
订单创建、库存预占和支付成功后的实际扣减，可能属于不同业务阶段。不要因为它们最终都影响库存，就把所有动作塞进一个超长事务。事务越长，锁持有时间越久，失败重试和补偿的边界越模糊。
一种常见方案是：订单创建后产生预占请求，库存服务在自己的事务中完成余额更新和预占流水写入，再返回处理结果；支付完成后产生实际扣减事件；订单取消时产生释放事件。每一步都需要幂等键，并允许失败重试。
这种方案不一定适用于所有系统。若系统规模很小、订单和库存位于同一数据库、业务要求强一致，可以采用同库事务简化实现；若系统已经拆分成多个服务，则需要明确最终一致性、消息可靠投递和对账机制，不能只把原来的本地事务拆成几个远程调用。
自增整数、随机 UUID、时间有序 ID 都可以作为主键，但它们的代价不同。自增整数索引紧凑、写入局部性好，适合单库或由数据库统一生成的场景；随机 UUID 全局生成方便，但索引体积和写入离散度通常更高；时间有序 ID 兼顾分布式生成与一定的写入顺序，但要处理时钟回拨、长度和解析问题。
| 主键方案 | 优势 | 风险 | 适用场景 |
|---|---|---|---|
| 自增整数 | 索引紧凑、查询和排序简单 | 跨库合并、暴露数量规律时不方便 | 单库交易系统、内部管理系统 |
| 随机 UUID | 分布式生成容易、跨系统冲突概率低 | 索引较大，写入位置分散 | 跨系统对象标识、对数据库顺序要求不高的场景 |
| 时间有序 ID | 适合分布式生成，写入相对有序 | 需处理时钟、编码长度和生成服务 | 高并发、多节点写入的业务表 |
我的建议是，先确认主键是否会被外部暴露、是否需要跨库合并、是否有高并发写入，再做选择。不要为了追求“架构感”给一个低并发后台表引入复杂 ID 服务，也不要因为自增简单，就把业务编号直接暴露给用户。
金额通常需要定点小数或以最小货币单位整数保存，避免浮点运算带来的精度误差。商品数量可能是整数，也可能允许 0.001 等小数；重量、长度和比例则需要根据计量单位与业务精度确定。
建议在表设计文档中同时写出字段单位。例如 quantity 到底表示件、箱、千克还是库存基本单位，不能只看字段名猜测。一个系统内部统一使用基本单位，展示层再转换，通常比在数据库里同时保存多个未经说明的单位更安全。
异步系统中，支付事件可能在 10:00 发生，10:03 才被服务消费并写入数据库。若只有 created_at，团队会误以为 10:03 才发生支付。对于订单、支付、库存和日志，至少应判断是否需要同时保留业务发生时间与系统落库时间。
时区也必须统一。跨地区系统如果把本地时间直接写入数据库，日终统计、跨天订单和过期任务都可能出现边界错误。更稳妥的方式是统一保存标准时间，展示时按用户或业务地区转换，并在字段说明中明确这一约定。
扩展字段适合存储第三方原始响应、低频使用的可选属性或暂时无法结构化的附加信息。但如果业务经常按某个 JSON 内部字段过滤、排序、关联或建立唯一性，就说明它已经成为稳定事实，应该重新评估是否拆成正式字段。
我会特别警惕名为 data、extra、content 的万能字段。它们短期减少了改表次数，长期却会让数据字典、权限控制、索引设计和质量校验变得困难。扩展字段不是不建模，而是把建模成本推迟到了查询、治理和迁移阶段。
如果系统规模不大、写入链路集中在一个应用、数据库由同一团队维护，建议优先采用清晰的关系模型和数据库约束。此时不必一开始就做分库分表、复杂事件总线或过度抽象的通用字段。
小系统最常见的错误不是性能不够，而是团队为了“以后扩展”加入大量无明确语义的类型字段和 JSON 字段。未来需求没有发生之前，不要用复杂结构提前支付维护成本。
当系统接入支付回调、仓储接口、消息队列和多个运营后台后，写入入口已经不再单一。此时必须把请求幂等、来源单号、状态历史、事务边界和失败补偿纳入表结构设计。
这个阶段不要只问“数据库能不能扛住”，还要问“发生重复消息、延迟消息和乱序消息时，数据是否仍然可解释”。很多一致性问题不是数据库性能问题，而是模型没有为重复和延迟预留位置。
高并发场景下，热点可能来自同一个商品、同一个账户、同一个门店或同一个时间分区。此时应先观察写入冲突、锁等待、更新失败和队列堆积，再决定采用分段库存、队列串行化、分区、分表或缓存策略。
如果直接按用户或订单号分表，却没有考虑库存热点，可能只是把查询拆开了，真正的写入竞争仍然集中在同一商品或仓库记录上。分片键要服务于访问和写入分布，而不是只服务于数据量切割。
交易数据库适合保证业务写入和实时查询，分析型场景则经常需要按天、渠道、商品、地区和组织层级进行聚合。若把所有分析字段、累计指标和宽表字段都加入交易表，读写性能、字段语义和数据治理都会变复杂。
更合理的路径通常是：交易表保存原始事实，经过同步或抽取后形成面向分析的明细事实表和汇总表。分析模型可以反范式化，但必须保留来源字段、更新时间和口径说明，避免“报表数字有了，却没人知道怎么算出来的”。
面对已有脏数据的老表，不建议直接重构或大规模拆表。第一步应该是统计重复键、空值分布、状态值分布、历史增长速度和慢查询。没有这些基线，改造后的效果无法证明，失败时也不知道问题来自数据、代码还是迁移。
如果其中任何一个问题无法回答，说明模型还处在“字段收集”阶段，不适合直接进入建表和开发。
单体系统、同库事务和数据写入入口集中时，外键可以有效阻止孤儿数据，并降低部分应用代码负担。对于关键主从关系，数据库层约束通常比团队约定更可靠。
跨库、分片或高频批量导入场景中，外键可能带来迁移、删除和写入协调成本。此时可以不使用物理外键，但必须用应用校验、异步对账、数据质量任务和明确的删除策略补足缺口。取消外键不是取消约束，而是把约束责任转移给了其他机制。
软删除适合需要恢复、保留历史或避免物理删除影响关联数据的场景。但软删除会让所有查询都增加过滤条件，也会让唯一索引变得复杂。例如一个用户被软删除后，是否允许重新注册同一手机号，取决于业务规则和数据库能力。
如果使用软删除，至少要明确删除时间、删除人、删除原因和唯一性策略。对合规或审计要求高的系统，软删除还不等于真正的数据隔离，仍需考虑权限、备份、归档和敏感数据清理。
状态少且稳定时，代码常量加数据库检查约束可能更简单；状态需要配置名称、排序、权限和多语言时，字典表更灵活；状态转换复杂时，单独的状态机配置或状态历史表更有价值。
不要因为“状态可扩展”就把所有状态做成可由运营随意配置。订单支付状态、资金处理状态等核心状态通常需要严格控制，任意配置可能绕过业务安全边界。
JSON 的优势是适应变化快、字段可选和减少频繁迁移，缺点是查询、校验、索引和数据治理成本更高。可以将第三方原始报文放入 JSON，但不要把订单金额、用户归属、库存数量这类核心事实藏在 JSON 中。
一个实用判断是：如果某个字段在过去三个月内被多个核心查询使用，或者它需要唯一性、权限控制和统计分析，就应考虑提升为正式字段。
如果当前瓶颈是单个热点键的并发更新，分表不一定解决问题；如果当前瓶颈是历史数据扫描和归档，分区或冷热分离可能比按业务键分表更合适；如果当前瓶颈是跨组织访问隔离，按租户或组织拆分才可能有价值。
| 问题表现 | 优先考虑 | 不应立即做的事 |
|---|---|---|
| 历史数据查询拖慢交易查询 | 归档、分区、读写隔离 | 直接按主键水平分表 |
| 单个商品或账户写入冲突 | 热点拆分、串行化、分段余额 | 只增加普通索引 |
| 数据量增长但访问集中度低 | 索引优化、冷热策略、容量规划 | 没有基线就分库 |
| 跨租户访问和权限隔离困难 | 租户键、分区或独立库评估 | 让每个查询临时拼接权限条件 |
一次高质量的表结构评审，不应该只拿一张 ER 图和一份 DDL。至少需要四份材料：业务流程图、核心查询清单、数据增长与访问量估算、迁移和回滚方案。
如果没有查询清单，索引评审只能停留在猜测；如果没有增长估算，分区和归档讨论只能停留在口号；如果没有迁移方案，再好的新结构也可能无法安全落地。
这十个问题的价值在于，它们会迫使设计者从“字段是否存在”转向“事实是否稳定、规则是否可执行、变化是否可验证”。表结构评审不是找语法错误，而是提前暴露未来需要付出的成本。
我通常把风险分为语义风险、数据风险和运维风险。语义风险包括一行粒度不清、字段多义和表职责混杂；数据风险包括重复写入、并发覆盖、非法状态和历史不可追溯；运维风险包括无法迁移、无法回滚、索引变更影响线上和缺少容量规划。
| 风险等级 | 典型问题 | 处理建议 |
|---|---|---|
| 高风险 | 无业务唯一键、余额无流水、金额精度不明、迁移无法回滚 | 阻断上线，先补设计和验证 |
| 中风险 | 状态历史不完整、索引未经真实参数验证、扩展字段缺少口径 | 限定范围上线，补监控和后续改造计划 |
| 低风险 | 命名风格不统一、注释不完整、非核心字段暂未拆分 | 记录改进项，不影响核心链路上线 |
分级的目的不是把所有问题都变成阻断项，而是避免团队把命名格式和资金重复扣款放在同一个优先级上。架构师必须判断哪些问题会形成不可逆的数据损失，哪些问题只是维护体验较差。
表结构上线后，真正值得监控的不是“表创建成功”，而是设计假设是否成立。建议持续观察重复键冲突次数、约束失败次数、慢查询扫描行数、锁等待时间、流水与余额对账差异、迁移回填速度等指标。
这些指标应与业务场景关联。例如库存系统不能只监控查询耗时，还要监控负库存率、重复扣减拦截次数和余额流水差异。一个库存查询平均 20 毫秒，但每天出现几十笔无法解释的数量差异，仍然是失败的设计。
平均查询耗时很容易掩盖问题。库存查询在大多数商品上可能很快，但热门商品在促销期间出现锁等待；订单列表平均 50 毫秒，但最后几页因为深分页需要扫描数百万行。架构评审要关注 P95、P99、峰值时段和异常参数，而不仅是平均数。
同样，数据质量也不能只看总体错误率。一个整体重复率低于千分之一的系统，如果重复集中在支付回调和库存扣减这两个关键链路，风险仍然很高。指标需要按业务动作、来源系统、租户、仓库和时间段分组，才能找到真实问题。
很多团队只记录数据库错误日志，却不记录人工修复。实际上，运营人员频繁改状态、技术人员频繁直接调整余额，说明表结构或流程没有提供足够的可解释性和纠错能力。
建议为人工调整建立专门的调整单或修复流水，记录调整前后值、原因、审批人和关联工单。这样既能防止“直接改库”成为隐性流程，也能在下次评审时判断哪些业务规则应该被正式建模。
设计说明不需要很长，但必须包含表的业务定义、数据粒度、生命周期、写入入口、核心查询和不可违反的约束。它的作用不是给文档系统增加一页内容，而是让评审者在看字段之前，先理解设计意图。
可以采用下面的简化模板：
| 项目 | 填写内容 |
|---|---|
| 表的职责 | 这张表只负责记录什么事实 |
| 一行粒度 | 一行数据代表什么对象、事件或快照 |
| 生命周期 | 创建、更新、完成、取消、归档和删除规则 |
| 核心写入者 | 接口服务、任务、后台、同步程序或人工工具 |
| 核心查询 | 详情、列表、统计、关联和定时处理查询 |
| 数据底线 | 唯一性、非空、精度、状态和幂等规则 |
| 增长估算 | 日新增量、峰值写入、保留周期和预计总量 |
| 变更方案 | 新增字段、回填、兼容发布、切换和回滚 |
每个字段至少写清楚名称、业务含义、数据类型、单位、是否必填、是否可修改、默认值、来源和使用方。对金额和数量字段，还要写精度；对状态字段，要写合法值和转换条件；对外部编号，要写来源系统和唯一性范围。
如果一个字段无法写出清晰的来源或修改规则，它很可能只是一个“先放进去再说”的字段。这样的字段越早被识别，后期清理成本越低。
不要只用正常流程测试表结构。至少模拟支付回调重复到达、库存扣减重试、订单取消与出库并发发生、商品改名后查看历史订单、数据库迁移中途失败、消息延迟到达以及人工调整后进行对账等场景。
一个结构如果只能在正常流程下工作，不能在异常流程下解释数据，就还没有达到生产级标准。生产系统最贵的不是多建一张流水表，而是事故发生后没有证据证明发生了什么。
第一，先定义一行数据代表什么，再决定字段和表的数量。粒度不清，所有后续规范都会变成表面工作。
第二，把当前状态和历史事实分开。余额、状态和统计结果方便读取，但流水、事件和快照才让系统具备解释能力。
第三，把未来变更当成设计输入。字段新增、状态扩展、数据回填、消息重试和历史归档不是上线后的附加问题，而是表结构是否合格的一部分。
可以选出系统中最重要的一张表，按本文顺序完成一次小型评审：先写一行粒度，再列出对象、事件、状态和快照；然后补充业务唯一键、非空规则、状态转换、核心查询和索引候选；最后模拟重复请求、并发更新、历史追溯和迁移失败。
如果这张表无法回答“为什么有这条记录、谁改变了它、如何防止重复、异常后如何恢复、数据增长后怎么查”，就不要急着继续加字段。先修正模型，再讨论性能优化。
表结构设计的最终产物不是一份漂亮的 DDL，而是一套让正确数据容易写入、让错误数据难以产生、让历史变化能够解释、让未来改造有路可走的工程约束。这才是架构师在数据库设计中真正需要交付的方案。
我以前做订单和库存系统时，最初的建表评审经常从字段开始：商品名称要不要存、状态有哪些、时间字段怎么命名。后来一次退款和补发需求同时上线，才发现真正的问题不是少了几个字段，而是一行数据到底代表“当前状态”、 “历史事件”还是“业务快照”没有定义清楚。表结构设计到底应该优先解决什么问题？
我现在评审表结构，第一句通常不是“字段够不够”，而是要求开发者先写清楚：一行数据代表什么事实。只要这句话说不清，后面的主键、索引和字段类型基本都属于提前装修。表结构至少要同时满足五个目标：业务语义清晰、数据约束可靠、核心查询可用、历史变化可追溯、未来变更可控。
其中最容易被忽略的是“事实”和“状态”的区别。例如库存场景中，stock_balance 表的一行可以表示“某仓库中某商品当前的库存余额”；而 stock_flow 表的一行表示“一次入库、出库或冲正事件”。前者会被更新，后者原则上只追加。
把两者合并成一张表，初期查询很省事，后续对账时却无法判断余额是如何变化的。设计目标要回答的问题常见失败表现 语义清晰一行数据代表什么事实？一个字段同时表示多个业务含义 一致性可靠重复、非法状态如何阻止？只能依赖代码判断，脏数据进入数据库 查询可用核心列表和详情如何查询？
上线后才发现需要全表扫描 可追溯数据为什么变成现在这样？只有更新时间，没有操作来源 可演进新需求如何兼容旧数据？新增一个字段就要同步改多个系统 我的判断是：如果一张表同时承担当前状态、历史流水、展示冗余和操作日志四种职责，应该优先拆分，而不是继续加字段。
订单主表保存订单当前状态，订单明细保存成交事实，状态变更表保存状态轨迹，操作日志则记录谁在什么时间做了什么动作。可以用三个检查问题快速判断表的职责是否清楚：这行数据是否会被反复修改？是否需要保留每次变化？是否存在多个不同生命周期的对象？如果三个问题中有两个答案是“是”，通常就值得重新审视表的边界。
我见过一张订单表直接用订单号作为主键，后来外部系统的订单号规则调整，导入历史数据时出现长度和格式冲突。还有一次，接口虽然在应用层检查了“订单是否已存在”，但并发请求还是插入了两条相同订单。我想知道数据库中的主键、业务唯一键和对外展示编号，究竟应该如何分工？
我更倾向于把“数据库行身份”“业务去重依据”和“对外展示编号”拆成三个概念，而不是让一个字段承担全部职责。这样做看起来多了字段，实际上降低了接口变更、数据迁移和并发幂等的风险。主键的职责是稳定识别一行数据，通常不应该承载业务含义。业务编号可能改规则、改长度、改生成系统，甚至需要兼容多个来源；
一旦把它直接作为主键，变化就会沿着外键、索引、接口和报表扩散。
字段类型主要职责是否适合直接做主键典型例子 内部主键稳定识别数据行适合id 业务唯一键防止同一业务事实重复通常不建议替代主键merchant_id + request_id 展示编号供用户、客服和外部系统沟通不建议order_no 以订单创建为例，我通常会保留一个内部主键 id，再设置 order_no 为唯一索引。
如果订单来自外部请求，还会增加 merchant_id 和 request_id，并建立联合唯一约束 UNIQUE(merchant_id, request_id)。这样即使同一个请求因为网络重试提交三次，数据库也只允许一条业务记录成功落库。
这里有一个容易踩坑的地方：应用层的“先查询、后插入”不能代替数据库唯一约束。两个并发请求可能同时查不到记录，然后同时插入。正确做法是让数据库约束负责最终兜底，再在应用层把唯一键冲突转化为幂等返回，而不是直接报系统异常。还要提前确认软删除与唯一索引的关系。
如果账号或商品允许删除后重新创建，单纯的唯一索引可能阻止新记录插入；如果使用逻辑删除，则需要结合数据库能力设计包含删除标记的唯一约束，或者采用归档表。不要把 deleted 字段当成自动解决所有重复问题的万能方案。
我曾经接手过一个列表查询变慢的系统，团队第一反应是给筛选字段全部加索引，结果写入耗时明显增加，慢查询却没有消失。后来用执行计划检查，才发现真正的问题是时间范围分页、排序字段和过滤条件组合不匹配。表结构设计时，索引到底应该怎样验证，库存扣减又该如何避免并发覆盖？
索引不是字段装饰品，而是针对具体访问路径建立的数据结构。我现在不会接受“这个字段经常查询，所以加索引”这种理由，而是要求评审者先写出最重要的查询，包括过滤条件、排序方式、分页方式和预期返回行数。例如订单列表常见查询是：按商户筛选指定状态，按创建时间倒序分页。
对应的组合索引通常要围绕 merchant_id、status 和 created_at 设计，但最终顺序仍要结合数据分布、查询比例和数据库执行计划验证，不能只背“最左匹配”规则。
验证项目我会重点看什么不通过时的处理 过滤条件是否覆盖高频等值条件调整组合索引顺序 排序与分页是否出现额外排序或深分页改为游标分页或补充排序列 执行计划扫描行数、回表次数、索引选择用真实数据量重新测试 写入成本新增索引是否拖慢插入和更新删除重复索引，降低索引数量 库存扣减则是另一个问题：索引解决的是“找到哪一行”，不能单独解决“并发时谁有资格修改”。
比较稳妥的做法之一，是在事务中执行带条件的更新，例如只允许 available_quantity >= 扣减数量 时减少库存，同时检查受影响行数是否为 1。受影响行数为 0，才能明确判断库存不足或记录不存在。
如果业务需要防止重复扣减，还应为来源单号建立唯一约束，例如仓库、商品和业务流水号的组合唯一键。单靠分布式锁或应用层判断，遇到超时重试时仍可能重复写入。我的经验是：幂等键负责防重复，条件更新负责防超卖，流水表负责追溯，这三个职责不要混在一个方案里。上线前至少要用接近生产规模的数据执行一次计划分析。
测试库只有几万行时，某些全表扫描看起来很快；当数据增长到数千万行，排序、回表和深分页的成本才会暴露。索引评审必须同时看读性能和写入代价，否则很容易用写入吞吐换来一个并不稳定的查询收益。
我以前做数据库评审时，通常重点检查字段类型和索引，却忽略了迁移顺序、历史回填和回滚方案。后来一次大表新增非空字段，发布脚本在生产环境执行时间远超预期，旧版本程序也无法正常写入。除了检查表能不能创建，还应该从哪些角度判断它是否真的可以上线？
一张表能成功执行 CREATE TABLE，只说明语法成立，不代表它具备上线条件。我的上线检查会分成业务语义、数据约束、查询性能、并发一致性和演进运维五组，因为很多事故并不是建表失败，而是发布后才发现旧程序、历史数据或高峰流量无法兼容。第一步是检查业务语义。
必须明确一行数据的含义、创建时机、修改主体和终止条件。对于订单、库存、账户这类对象，还要区分“当前余额”与“变化流水”、“业务发生时间”与“系统写入时间”，否则发生补录、重试或异步延迟时，时间线会被混在一起。第二步是检查约束。
至少要回答：主键是否稳定，业务唯一键是什么，哪些字段必须非空，非法状态如何阻止，删除后是否允许重建，跨表关联失败时如何处理。能由数据库保证的规则，不要全部寄托在应用代码上；但跨库和异步场景也不能假设数据库外键可以解决所有一致性问题。第三步是检查查询和增长。
不要只验证当前数据量，还要估算一年后的记录数、每天增长量和最常见的时间范围。
以下是我会放进评审单的最小检查表： 检查项必须确认的内容常见风险 数据增长日增量、保留周期、归档策略历史数据无限膨胀 字段变更新增、重命名、废弃和回填方案旧版本程序读取失败 大表迁移锁影响、执行时长、分批策略发布阻塞线上请求 回滚DDL、数据回填和应用版本如何退回只能回滚代码，无法恢复数据 审计恢复操作人、来源、请求号和恢复路径出现异常后无法定位 第四步是做兼容性发布。
新增字段时，通常先发布能忽略新字段的旧逻辑或兼容代码，再扩展表结构，随后回填数据，最后切换读取逻辑。对大表而言，新增字段是否允许默认值、是否会触发表重建、是否需要在线变更，都要先在同版本数据库和近似数据量环境中演练。
最后，我会要求团队写出四个故障场景的处理方式：重复请求、并发更新、部分写入成功、迁移执行到一半失败。如果这些问题只能回答“应用层会重试”或“后续人工修复”，说明表结构还没有把一致性和可恢复性考虑完整。好的设计不是永远不出错，而是出错后能定位、隔离、补偿并且不破坏历史事实。
读者评论
文章把“当前余额”和“历史流水”拆分的思路很实用，尤其适合库存、账户这类需要追溯的场景。不过实际落地时，还要结合事务一致性、对账和异常补偿机制一起设计。
一行代表什么事实”这个检查点很关键。很多表结构问题并不是字段类型选错，而是快照、事件和状态混在了一起，导致后续查询和维护都变得困难。
文中强调数据库约束不能完全依赖应用层，这一点比较客观。唯一键、非空和金额类型等规则确实应该尽量落到数据库，但复杂业务状态仍需要应用层配合校验。
库存案例对系统演进中的风险说明得比较清楚，特别是没有流水导致无法解释历史变化。不过文章主要是原则性建议，若能补充并发扣减和索引执行计划示例，会更便于实践。
表结构设计同时关注查询、审计和演进，而不是只追求当前性能，这个观点值得借鉴。实际项目中还应根据数据量、访问频率和数据库类型调整具体方案。