《数据库存：架构师选型思路：表结构设计应重点评估数据校验》这件事，真正难的不是会不会写 CREATE TABLE，而是要判断：一条错误数据究竟应该在哪一层被拦截，以及当系统有多个写入入口时，谁能成为最后一道防线。我在做订单、客户和经营分析系统的表结构评审时，反复遇到同一种问题：接口层明明写了参数校验，数据库里仍然出现重复订单号、负金额、孤儿明细和无法识别的状态值。

后来复盘发现，问题往往不在某个字段漏写了校验，而在于数据库选型和表结构设计阶段，根本没有把“数据校验能力”当成架构指标。

我的核心判断是：数据库选型不能只比较查询速度、存储成本和扩展能力，还要评估它能否用稳定、可观察、可迁移的方式守住数据完整性。表结构中的非空、唯一、范围、引用和并发约束，决定了错误数据能否进入系统；应用层的业务校验，决定了用户行为是否符合流程；数据治理和对账机制，则负责处理跨系统、历史数据和最终一致性问题。三者不是互相替代，而是责任边界不同。

一、先讲结论：数据校验是数据库选型的隐藏主指标

1. 表结构设计不是字段清单，而是一份数据契约

很多团队评审表结构时，首先关注表名、字段名、索引和分库分表方案，却很少逐字段追问“这个字段允许什么、不允许什么”。例如，订单金额是否允许为空，订单号是否全局唯一，商品数量能不能为零，订单明细能不能脱离订单存在，这些都不是编码风格问题，而是系统对事实的定义。

一旦这些定义没有进入表结构或其他强制机制，系统实际上就会允许多种互相矛盾的事实同时存在。应用程序认为订单金额必须大于零，脚本却可以写入负数；前台认为邮箱不能重复，导入程序却绕过了接口；订单服务认为明细必须有主订单，清理任务却先删了主表记录。

因此，我会把一张表看成一份可以执行的数据契约。字段类型描述“它是什么”，非空约束描述“它是否必须存在”，唯一约束描述“它能否重复”，检查约束描述“它的值域是什么”，外键或等价机制描述“它与谁有关”。如果这些信息只停留在接口文档里，数据库就无法替整个系统守住底线。

2. 不是所有校验都应该下沉到数据库

强调数据库约束，并不意味着把所有业务规则都写入数据库。数据库适合保证稳定、明确、跨入口都必须成立的事实，例如订单号不得重复、金额不能为负、子记录必须关联有效主记录。

但“用户是否有资格领取优惠券”“当前订单是否允许退款”“这个客户是否超过授信额度”等规则，通常依赖权限、时间、库存、风控结果和外部系统。它们应该由应用服务或领域服务负责，数据库承担必要的并发保护和最终一致性兜底。

好的架构不是让数据库承载最多规则，而是让每条规则落在最适合、最可靠、最容易演进的地方。选型时真正要问的不是“这个数据库功能多不多”，而是“我的关键事实能否被稳定验证，以及验证失败后能否被正确处理”。

3. 约束能力必须和迁移能力一起评估

有些数据库支持丰富的约束语法，但线上增加约束的代价很高；有些系统理论上支持某项约束，但在特定版本、存储引擎或分布式部署模式下，行为和单机测试不同。只在建库阶段看功能列表，容易得到一个“功能很完整、上线很痛苦”的方案。

我在评审约束时，通常同时看四个问题：

• 约束能不能真正执行，而不是只被解析或记录在元数据中？
• 并发写入时，约束失败是否具有确定性？
• 给已有大表增加约束，是否需要长时间锁表或全表扫描？
• 历史脏数据、迁移失败和回滚，是否有可操作的处理路径？

如果一个数据库拥有很强的完整性能力，却无法在业务持续写入时安全完成约束变更，那么它的能力就不能简单记为“支持”。在架构决策中，可用的约束能力 = 语法支持 × 运行时行为 × 变更可行性 × 团队执行能力。

二、为什么应用层校验之后，数据库里仍然会出现脏数据

1. 一个接口不是数据的唯一入口

在简单单体系统里，开发人员容易形成一种错觉：前端提交请求，后端完成参数校验，数据库只负责保存。系统运行几个月后，真实写入入口往往会变成一张复杂的网络。

• 用户端接口负责正常交易。
• 运营后台负责修改状态、补录客户和修复订单。
• 定时任务负责关闭超时订单、计算余额和生成结算记录。
• 消息消费者负责接收支付、库存或物流事件。
• 数据导入任务负责批量导入客户和商品资料。
• 分析平台或数据同步任务负责抽取、清洗和写入中间表。
• 紧急故障处理时，工程师可能直接执行修复脚本。

只要存在两个以上写入入口，应用层校验就不再是完整防线。每个入口都可能有不同的代码版本、不同的校验顺序和不同的异常处理方式。更麻烦的是，旁路任务通常没有前台接口那么完整的测试覆盖。

我曾经遇到过一个客户资料导入问题：接口规则要求手机号不能为空，但历史导入模板把空手机号表示为空字符串，数据库字段又允许空值和空字符串并存。结果是报表按 IS NULL 统计时得到一组数字，按字符串长度统计时又得到另一组数字。表面看是报表口径问题，根源其实是表结构没有明确“缺失”的表示方式。

2. 应用层的“先查后写”挡不住并发重复

最常见的重复数据写法是：应用先查询订单号是否存在，如果不存在再执行插入。单线程测试完全正常，但两个请求几乎同时到达时，它们都可能在插入前查到“没有记录”。

-- 应用层先查询
SELECT id FROM orders WHERE order_no = 'SO202609160001';

-- 查询为空后，两个并发请求分别执行插入

INSERT INTO orders(order_no, user_id, amount)

VALUES ('SO202609160001', 10086, 199.00);

如果表上没有唯一约束，两个请求都可能成功；如果有唯一约束，一个成功、一个失败。第二种结果才是可控的，因为数据库把“订单号只能有一个”从建议变成了事实。应用层仍然需要处理失败原因，但不再需要自己证明全世界没有另一个并发请求。

这里有一个容易被忽略的判断：应用层校验负责改善用户体验，数据库约束负责阻止事实被破坏。前者可以给出“订单号已存在”的友好提示，后者负责在竞态条件下真正拒绝重复写入。

3. 数据同步和分析任务会放大结构缺陷

业务数据库里的一个空值，进入数据仓库或经营分析系统后，可能变成一个分类项；一个状态拼写错误，可能被当成新状态；一个重复客户，则可能让销售额、客户数和复购率同时失真。

以经营分析场景为例，如果业务表中同一个客户存在多个编码，分析人员可能在导入数据时进行人工合并。短期看，报表似乎恢复正常；长期看，每次增量更新都要重复处理映射关系，且无法判断哪些合并是有依据的，哪些只是临时修补。

如果企业使用九数云这类数据分析平台进行多源数据连接，表结构中的数据质量问题不会自动消失，只会更早暴露在指标、透视表和仪表板中。这个场景的重点不是把分析平台当成数据库约束替代品，而是要在源表阶段明确主键、业务唯一键、时间字段和维度编码，减少后续清洗的隐性成本。

三、表结构设计中最容易被低估的五类校验

1. 空值、空字符串和默认值不是一回事

“允许为空”是很多表结构评审里最容易被一笔带过的内容。数据库中的 NULL 通常表示未知、缺失或不适用；空字符串则是一个确定的字符串值；默认值则意味着调用方没有传值时，数据库主动替它填入某个值。三者如果没有业务定义，统计和查询很快会出现歧义。

例如，客户的联系电话字段允许 NULL，表示客户尚未提供；空字符串表示客户明确没有电话；默认填充“未知”，则又代表系统把缺失状态编码成普通文本。三种设计都可能成立，但不能混用。

我的建议是先给字段写出“缺失语义”，再决定是否允许空值：

• 核心身份字段、订单号、金额和创建时间，通常不应允许为空。
• 确实可能在业务后置阶段补齐的字段，可以允许为空，但要明确补齐流程。
• 不要用默认值掩盖调用方漏传，尤其是金额、状态和权限字段。
• 对字符串字段明确空字符串是否等价于缺失，并在接口层统一处理。

2. 唯一性必须按照业务语义设计

单列唯一并不等于业务唯一。多租户系统中，客户编码可能只要求“租户内唯一”，而不是全平台唯一；软删除系统中，历史记录可能不应该阻止新记录重新使用相同编码；邮箱比较还可能涉及大小写、空格和字符集规则。

因此，看到“这个字段要加唯一索引”时，我不会立即确认，而是继续问：

• 唯一范围是全局、租户内，还是某个业务周期内？
• 逻辑删除后的记录是否继续占用这个值？
• 大小写不同的值是否应该视为同一个值？
• 导入、重试和并发请求是否使用同一个幂等键？
• 历史数据中是否已经存在重复值？

一个典型的订单表可能需要同时存在三个不同概念：数据库自增主键、对外展示的订单号、支付渠道返回的交易号。它们的生成方式和唯一范围不同，不能因为都叫“编号”就只设计一个字段。

3. 数值范围约束比字段类型更进一步

使用 DECIMAL(18,2) 能够控制金额精度，却不能自动阻止负数；使用整数类型能避免小数，却不能说明数量是否允许为零。字段类型解决的是数据表示问题，范围约束解决的是业务值域问题。

CREATE TABLE order_item (
id BIGINT NOT NULL PRIMARY KEY,
order_id BIGINT NOT NULL,
product_id BIGINT NOT NULL,
quantity INT NOT NULL,
unit_price DECIMAL(18, 2) NOT NULL,
item_amount DECIMAL(18, 2) NOT NULL,
CONSTRAINT ck_order_item_quantity CHECK (quantity > 0),
CONSTRAINT ck_order_item_unit_price CHECK (unit_price >= 0),
CONSTRAINT ck_order_item_amount CHECK (item_amount >= 0)
);

需要注意的是，金额校验不能只看明细金额是否大于零，还要明确它是否必须等于数量乘以单价、是否允许折扣、是否允许手工改价。如果金额计算涉及促销、税费和舍入，数据库很难独立表达完整规则，通常应由服务层计算，并通过快照字段保留当时的结果。

4. 状态值合法，不代表状态流转合法

订单状态字段使用整数或字符串时，可以限制它只能取“待支付、已支付、已完成、已取消”等合法值。但这只能防止拼写错误或无效编码，不能防止订单从“待支付”直接跳到“已完成”。

状态值校验属于记录层约束，状态流转属于流程层约束。前者可以用枚举、检查约束或字典表处理；后者则需要条件更新、版本号、状态机或领域服务来处理。

UPDATE orders
SET status = 'PAID',

paid_at = CURRENT_TIMESTAMP,

version = version + 1

WHERE order_no = 'SO202609160001'

AND status = 'PENDING_PAYMENT'

AND version = 3;

如果更新影响行数为零，应用必须继续判断是订单不存在、状态已经变化，还是版本冲突。仅仅把状态字段定义为字符串，并不能解决并发状态覆盖。

5. 外键要看边界，而不是迷信或排斥

在同一个数据库、同一个事务边界内，外键能够有效防止孤儿记录。例如订单明细必须关联存在的订单，删除订单时不允许留下无主明细。这类关系完整性通常值得由数据库直接保障。

但在分库分表、跨服务数据库或大规模写入场景中，物理外键可能带来额外耦合。订单服务和商品服务各自拥有数据库时，订单表无法用普通外键约束商品库；这时应采用商品快照、事件校验、异步对账和补偿机制。

不用外键不等于不用引用完整性。它意味着完整性从数据库内置约束转移成应用协议、消息机制和治理流程。转移之后必须留下替代方案，否则只是把显式约束变成了隐式风险。

四、架构师应该如何划分数据校验责任

1. 字段层负责“这个值能不能存在”

字段层校验是最基础的一层，主要回答数据类型、格式和是否缺失。它不应该被视为低级工作，因为大量线上脏数据都源自这些最基础的定义不清。

我的经验是，字段层规则越稳定，越应该靠近数据库。因为稳定规则的价值不在于灵活，而在于无论谁写入都不能绕过。相反，频繁变化的格式或策略规则，不宜频繁修改数据库结构。

2. 记录层负责“这一行是否自洽”

记录层校验关注同一行内部多个字段之间的关系。例如，优惠金额不能大于原价，结束时间不能早于开始时间，已支付订单必须存在支付时间。这些规则有的可以用检查约束表达，有的则需要服务层在事务内完成。

在设计这类规则时，我会把它们分成“无上下文规则”和“有上下文规则”。无上下文规则只依赖当前行，例如金额大于等于零，适合下沉；有上下文规则依赖其他表或外部状态，例如支付时间必须来自支付渠道回调，通常需要应用层和审计字段共同保证。

3. 关系层负责“多行数据是否形成有效事实”

关系层是表结构设计最能体现架构取舍的地方。一个订单和多条明细之间，是不是必须存在主从关系？删除订单时，明细是级联删除、禁止删除，还是保留并标记失效？这些决定会影响数据恢复、审计、归档和报表。

如果业务要求订单一旦生成就必须保留历史，物理删除往往不是好方案。此时可以采用软删除或归档表，但必须重新设计唯一性和查询条件。软删除后直接给业务唯一字段加普通唯一索引，可能导致已删除记录仍然阻止新记录创建。

在支持条件唯一索引的数据库中，可以考虑只对有效记录建立唯一性；如果目标数据库不支持，就需要使用组合字段、状态映射字段或服务层生成新的业务键。关键不是照搬某种语法，而是先定义“有效记录”的范围。

4. 流程层负责“这次变化是否合理”

流程层通常涉及状态机、权限、时间窗口、库存和外部结果。它不能被简单压缩成一个字段约束。比如订单从待支付变成已支付，至少要确认支付结果、幂等号、金额匹配和当前版本。

我通常会要求团队把流程规则写成状态转换表，而不是只写在接口代码里：

这张表不一定全部落入数据库约束，但它能够让架构师判断哪些规则需要唯一索引、哪些规则需要事务、哪些规则需要消息幂等，避免把复杂流程误认为“加一个状态字段就完成了”。

五、用订单系统做一次完整的表结构评审

1. 先确定订单表的不可破坏事实

订单系统看似适合做示例，实际上非常能暴露表结构设计的问题。因为它同时包含身份、金额、状态、时间、引用关系、幂等和审计等多类约束。评审订单表时，我不会先问“要不要分库”，而会先列出无论系统如何扩展都不能破坏的事实。

• 每个订单必须有唯一的业务编号。
• 每个订单必须能够识别所属用户或客户主体。
• 订单金额必须有明确精度、币种和计算口径。
• 订单状态只能来自定义好的状态集合。
• 订单创建时间和业务发生时间不能混为一谈。
• 订单支付结果必须能关联外部交易号。
• 订单明细不能在没有订单主体的情况下独立成为有效事实。

这些事实中，有些适合放在数据库约束里，有些适合通过服务、消息和对账保证。先写清楚不可破坏事实，再决定技术落点，比先争论数据库产品更有效。

2. 一份基础表结构并不能代表完整设计

CREATE TABLE orders (
id BIGINT NOT NULL PRIMARY KEY,

order_no VARCHAR(32) NOT NULL,

tenant_id BIGINT NOT NULL,

user_id BIGINT NOT NULL,

status VARCHAR(24) NOT NULL,

total_amount DECIMAL(18, 2) NOT NULL,

currency CHAR(3) NOT NULL,

payment_trade_no VARCHAR(64),

version INT NOT NULL DEFAULT 0,

created_at TIMESTAMP NOT NULL,

updated_at TIMESTAMP NOT NULL,

CONSTRAINT uk_orders_tenant_order_no

UNIQUE (tenant_id, order_no),

CONSTRAINT ck_orders_total_amount

CHECK (total_amount >= 0),

CONSTRAINT ck_orders_status

CHECK (status IN ('PENDING_PAYMENT', 'PAID', 'COMPLETED', 'CANCELLED'))

);

这份结构可以表达一些基础事实：订单号在租户内唯一，金额不能为负，状态不能超出定义集合，版本号用于并发控制。但它仍然没有回答很多问题。

• 订单号是否由数据库生成，还是由业务服务生成？
• 同一个支付交易号是否允许对应多个订单？
• 订单完成是否必须存在支付时间？
• 取消订单是否需要记录取消原因和操作者？
• 币种改变后金额是否允许重新计算？
• 软删除或归档后，租户内订单号是否可以复用？

这正是“表结构设计应重点评估数据校验”的核心：约束不是越多越好，而是要覆盖关键事实，同时把无法在表内表达的规则明确交给其他机制。

3. 订单明细要防止三种常见错误

第一种错误是孤儿明细，即明细记录存在，但订单主体已经不存在。单库单事务场景下，外键是直接有效的保护；跨库场景下，则要由订单创建协议和异步对账共同保证。

第二种错误是数量和单价非法。数量为零会造成无意义明细，负数量可能被误用为退货，但如果退货是正式业务，就应该使用独立的退货明细或明确的业务类型字段，而不是让普通订单明细随意接受负数。

第三种错误是同一订单内商品重复。是否允许重复取决于业务：购物车可能允许多次加入后合并，促销拆单可能允许同一商品出现在不同明细，但财务明细通常需要明确的行号和来源。不要为了“看起来干净”盲目加 UNIQUE(order_id, product_id)，否则促销、批次和价格快照可能无法表达。

4. 业务金额不能只靠数据库的简单范围检查

金额字段最容易成为“看起来有约束、实际上仍不可信”的地方。total_amount >= 0 只能防止负数，不能保证订单总额等于明细合计，也不能判断折扣、税费和运费是否符合业务规则。

在实际系统中，我倾向于把订单金额拆成多个不可混淆的字段，例如商品原价、折扣金额、运费、税费、应付金额和实付金额。每个字段都定义精度、符号和计算时点，并保留计算来源。这样做的代价是字段更多，但在对账、退款和历史追溯时，远比只保存一个总金额可靠。

如果使用分析平台汇总经营数据，还应明确报表采用应付金额、实付金额还是含税金额。九数云这类工具可以帮助连接订单、支付和商品数据，但它无法替业务方判断“收入”应该使用哪个金额字段。源表没有稳定口径，分析工具只能把歧义更快地展示出来。

六、数据库选型时，如何真正测试数据校验能力

1. 不要停留在产品宣传页的“支持”二字

数据库文档中写“支持外键”或“支持检查约束”，并不等于你的部署模式下就能按照预期工作。需要明确数据库版本、存储引擎、分片方案、事务模式和驱动行为，再做最小可运行验证。

我会把验证分成四组：定义验证、执行验证、并发验证和变更验证。定义验证看建表语句是否成功；执行验证看非法数据是否确实被拒绝；并发验证看同时写入时是否出现重复或不一致；变更验证看线上数据量增加后能否安全新增约束。

2. 用最小实验验证约束是否真的生效

以唯一约束为例，不能只在单线程里插入两次。至少需要验证重复插入、并发插入、事务回滚、重试和异常分类。以检查约束为例，需要测试空值行为、边界值、负数、小数精度和批量导入。

-- 1. 验证重复业务键
INSERT INTO orders

(order_no, tenant_id, user_id, status, total_amount)

VALUES ('SO202609160001', 7, 10086, 'PENDING_PAYMENT', 199.00);

INSERT INTO orders

(order_no, tenant_id, user_id, status, total_amount)

VALUES ('SO202609160001', 7, 10087, 'PENDING_PAYMENT', 299.00);

-- 2. 验证边界值

INSERT INTO orders

(order_no, tenant_id, user_id, status, total_amount)

VALUES ('SO202609160002', 7, 10088, 'PENDING_PAYMENT', -0.01);

-- 3. 验证非法状态

INSERT INTO orders

(order_no, tenant_id, user_id, status, total_amount)

VALUES ('SO202609160003', 7, 10089, 'DELIVERING', 399.00);

测试报告不能只写“失败了”，而应记录失败码、异常类型、事务状态和应用层处理方式。对业务来说，重复请求通常不是系统故障，而是幂等结果；连接中断、死锁和约束冲突则需要不同的重试策略。

3. 并发测试比单元测试更接近真实风险

唯一性和状态流转问题，往往在并发下才暴露。可以准备固定的业务键，让多个线程或多个客户端同时执行插入，再统计成功次数、重复次数、约束失败次数和死锁次数。

一个可执行的并发验证流程如下：

1. 准备一个确定的租户和业务编号。
2. 让 50 或 100 个并发请求同时提交相同订单。
3. 记录数据库成功写入数、唯一冲突数和服务返回码。
4. 检查最终表中是否只有一条有效业务记录。
5. 重复测试网络超时后的客户端重试场景。
6. 验证失败请求是否会产生重复消息、重复扣库存或重复支付单。

如果最终结果只有一条订单，但消息表、库存表和支付流水出现多条记录，说明数据库唯一约束只守住了一个局部事实，整个幂等链路仍然不完整。

4. 线上变更测试决定约束能不能落地

为大表增加唯一索引或非空约束，真正的难点通常不是 SQL 语法，而是存量数据和锁影响。应先统计重复值、空值和非法范围，再制定清洗方案。没有清洗计划的约束变更，通常会在发布窗口才发现无法执行。

我建议把约束上线拆成几个阶段：

• 先增加监控，统计未来约束会拒绝的写入。
• 再清理历史重复、空值和非法记录。
• 通过影子表或离线校验确认清洗结果。
• 选择低峰期建立索引或增加约束。
• 观察写入失败率、锁等待和接口错误率。
• 保留回滚脚本和异常记录，避免只准备正向发布。

七、不同业务场景下的选型判断

1. 交易、支付和账务系统：优先保证强一致和可追溯

这类系统最怕的不是单次查询慢，而是金额、账户和流水出现无法解释的矛盾。订单号、支付流水号、账务分录号等业务键通常需要明确唯一性；金额字段需要精度控制；关键更新需要事务、版本号或条件更新；所有修复都应留下审计痕迹。

在这种场景下，我通常会优先选择约束能力成熟、事务语义清晰、故障处理经验丰富的关系型方案。即使未来需要分库，也应先明确哪些事实必须在同一事务边界内完成，哪些可以通过消息和对账最终一致，而不是一开始就为了扩展性放弃约束。

适合下沉的规则包括业务键唯一、金额非负、流水不可重复和账户记录必须关联主体。不适合完全下沉的规则包括复杂风控、支付渠道状态判断和跨机构清算，它们需要服务层编排和对账机制。

2. 内容、日志和事件系统：允许部分弱约束，但不能没有数据协议

日志和事件数据通常写入量大、结构变化快，完全使用强关系约束可能增加写入成本和演进负担。但“允许结构变化”不等于“允许任何数据进入”。事件名称、事件时间、来源系统、事件版本和幂等标识仍然需要协议约束。

我会把事件数据分为两类：原始事件和规范事件。原始事件保留来源格式，方便追溯；规范事件进入分析或下游消费前，要求关键字段齐全、版本可识别、事件 ID 不重复。这样既保留灵活性，又避免下游每次重新猜字段含义。

如果事件用于经营分析，建议在进入分析平台前完成标准化。使用九数云等工具做多源分析时，重点不是要求平台替所有来源表建立强外键，而是确保每个来源都有稳定的业务主键、统一的时间口径和明确的维度映射。

3. 多租户业务系统：唯一性边界比索引数量更重要

多租户系统最常见的错误是把租户内唯一误设计成全局唯一，或者反过来把本应全局唯一的支付流水只限制在租户内。表结构必须明确每个业务键的作用域。

如果系统未来可能拆分租户数据库，应提前记录唯一性责任的迁移方案。原来依靠数据库全局唯一的字段，拆库后可能只能依靠 ID 生成中心或业务服务协调。这个变化需要在选型阶段就被记录，而不是拆库当天才发现。

4. 分库分表系统：放弃物理约束后必须补齐治理机制

分库分表后，跨分片外键通常不可行，跨分片唯一性也变得复杂。很多团队在这一步只做了路由和扩容，却没有重新设计数据校验责任，最终出现一个分片内唯一、全局重复的业务编号。

这类系统至少需要补充：

• 全局唯一 ID 或带分片信息的业务编号。
• 幂等键登记表或幂等服务。
• 异步引用校验和定期对账。
• 跨分片删除、归档和修复流程。
• 写入失败、重复冲突和补偿失败监控。

如果团队没有成熟的消息、对账和数据修复能力，分库分表带来的扩展收益可能抵不过完整性风险。架构复杂度不是免费的，失去数据库约束后，必须用流程、代码和运维能力把它买回来。

八、哪些常见做法看似稳妥，实际上会留下风险

1. 只在接口层做校验

这是最常见的做法，也最容易在早期项目中被接受。接口层校验确实能提供友好的错误信息，但它无法覆盖导入、脚本、消息和多服务写入。更重要的是，接口层校验通常是“先读后写”，在并发场景下无法独立保证唯一性。

正确做法不是删除接口校验，而是让接口层和数据库各司其职：接口层负责格式提示、参数组合和用户体验；数据库负责唯一、非空、范围和引用等稳定事实。两层都做并不重复，而是前者减少无效请求，后者防止绕过入口。

2. 把所有字段都设置默认值

默认值可以减少插入失败，但也可能隐藏严重问题。比如调用方漏传订单状态，数据库自动写入“待支付”，看起来数据合法，实际上调用方可能已经丢失了业务分支；金额漏传后默认成零，则会产生一笔形式上存在、实际上没有价值的订单。

我会把默认值分成两类。系统生成类默认值，例如创建时间、版本号和逻辑删除标记，通常比较安全；业务含义类默认值，例如订单状态、金额、审批结论，则需要谨慎，除非业务明确规定缺省就代表某个状态。

3. 用触发器解决所有跨字段和跨表规则

触发器能够在数据库内部自动执行逻辑，对某些审计和简单派生场景很有价值。但它也会让写入行为变得隐蔽：应用执行一条插入，实际触发了多个表的修改，调试、迁移和回滚都更复杂。

如果规则需要调用外部系统、发送消息或频繁变化，触发器通常不是合适位置。即使使用触发器，也应建立清晰的命名、审计和测试规范，并记录触发器造成的副作用。不能因为它“离数据近”，就把它当成万能业务引擎。

4. 盲目使用外键或盲目取消外键

外键不是性能原罪，也不是完整性圣杯。在同库强事务场景，它可以显著降低孤儿数据风险；在跨服务场景，它可能无法跨越数据库边界。真正需要评估的是写入规模、删除策略、锁行为、归档方式和团队运维能力。

如果决定不使用外键，架构文档中必须写清楚替代机制：谁负责检查引用、多久对账一次、异常如何修复、删除如何通知下游、数据修复是否可审计。没有替代机制的“去外键”，只是把风险藏起来。

5. 只看建表成功，不测失败路径

很多数据库评估报告会展示表成功创建、查询能返回结果，却不展示非法写入、并发冲突和迁移失败。对数据校验来说，失败路径比成功路径更有价值。

评估报告至少应包括以下内容：

• 重复业务键的返回行为。
• 空值、边界值和非法枚举的拒绝行为。
• 并发创建和并发更新的最终结果。
• 事务中途失败后的回滚结果。
• 批量导入遇到单条非法记录时的处理方式。
• 新增约束对锁、延迟和错误率的影响。

九、数据校验改造的可执行落地流程

1. 第一步：盘点数据入口和业务事实

不要直接打开数据库管理工具就开始加约束。先画出写入入口清单，至少包括接口、后台、脚本、消息、导入、同步和人工操作。对于每个入口，记录谁调用、写哪些表、是否支持重试、失败后是否回滚。

然后为核心表列出不可破坏事实。例如客户表的身份证明不能重复，订单表的业务编号不能重复，订单明细必须能找到订单，账务流水不能被更新覆盖。事实清单不需要一开始就很长，但必须覆盖高价值数据和高风险操作。

2. 第二步：把规则分成四种类型

我建议使用“字段、记录、关系、流程”四层分类。字段规则关注类型和空值；记录规则关注一行内部的值域和组合；关系规则关注多表引用；流程规则关注状态、权限和时间。

分类的价值在于避免技术争论失焦。有人说“应该由数据库校验”，有人说“应该由应用校验”，双方可能其实在讨论不同类型的规则。把规则放进四层后，再依据稳定性、入口数量、并发风险和变更频率决定具体落点。

3. 第三步：先查存量数据，再增加约束

新增约束之前，必须先回答历史数据是否已经符合规则。对于非空约束，统计空值和空字符串；对于唯一约束，找出重复分组；对于外键，寻找无法关联主表的明细；对于范围约束，统计越界值和产生来源。

-- 查找重复业务编号
SELECT tenant_id, order_no, COUNT(*) AS record_count

FROM orders

GROUP BY tenant_id, order_no

HAVING COUNT(*) > 1;

-- 查找金额异常

SELECT COUNT(*) AS invalid_amount_count

FROM orders

WHERE total_amount < 0

OR total_amount IS NULL;

-- 查找可能的孤儿明细

SELECT oi.id

FROM order_item oi

LEFT JOIN orders o ON o.id = oi.order_id

WHERE o.id IS NULL;

查询结果不能只用于删数据。每类异常都应追溯来源：是旧版本代码、人工导入、同步延迟、逻辑删除设计，还是并发缺少幂等。只清理结果、不修复入口，约束上线后仍会不断产生相同问题。

4. 第四步：建立“约束失败即产品反馈”的机制

数据库拒绝写入后，应用不能简单返回“系统异常”。需要根据错误类型区分重复、非法状态、数据缺失、引用失效、死锁和连接失败。不同错误的处理方式不同：重复通常返回幂等结果或业务提示，死锁可以有限重试，引用失效需要告警和人工排查，连接失败则进入基础设施故障流程。

监控中也不要只统计接口 500。建议单独记录约束冲突次数、冲突表、冲突字段、来源服务和业务场景。这样才能发现某个导入任务正在持续制造重复客户，或者某个新版本把状态流转顺序改错了。

5. 第五步：让数据分析反向验证表结构

表结构评审不能只由研发闭门完成。让财务、运营、数据分析人员参与，往往能提前发现字段语义问题。例如“客户数”是按客户 ID 统计，还是按手机号去重；“订单金额”是下单金额还是实付金额；“完成时间”是发货完成还是支付完成。

在使用九数云等分析工具连接业务库、表格和外部平台时，可以把这些指标口径做成验证场景：如果同一指标需要大量人工去重、手动映射和反复解释，通常说明源表的业务键、状态字段或时间字段设计不够稳定。分析结果不是表结构设计的附属品，而是检验数据契约是否真正可用的一面镜子。

十、不同情况下的行动建议与取舍

1. 如果系统仍是单体单库

单体单库是最适合建立数据完整性底线的阶段。建议优先把非空、唯一、金额范围、基础状态值和关键外键补齐。此时数据库和应用共享事务边界，很多规则可以用低成本方式获得较强保护。

但不要因为结构简单就把所有逻辑塞进存储过程或触发器。流程规则仍应有清晰的服务层表达，数据库重点保证不变量。单体阶段建立的业务键和审计字段，也会成为未来拆分服务时的重要基础。

2. 如果系统正在拆分微服务

微服务拆分时，首先要重新画数据所有权边界。原来一条事务可以同时修改订单、库存和支付，拆分后可能变成多个本地事务和一条事件链。数据库约束仍然有效，但只能保护本地事实，不能自动保护跨服务一致性。

此时建议为每个事件设计事件 ID、业务幂等键、版本号和来源时间。消费方应记录已处理事件，生产方应保证本地事务与消息记录的一致性。跨服务引用则通过异步校验、定时对账和补偿机制维护。

取舍是明确的：拆分提升了独立扩展和团队自治，但会牺牲部分数据库级约束的覆盖范围。只有当团队能够承担消息重复、乱序、延迟和补偿，拆分才是完整的架构方案。

3. 如果系统数据量很大、写入峰值很高

高写入系统需要评估约束带来的索引维护、锁竞争和存储开销，但不能把“高并发”直接等同于“不要约束”。真正应做的是区分关键约束和可异步校验规则。

• 业务唯一键、幂等键和账户安全边界，通常属于关键约束。
• 复杂跨表统计、历史一致性和低价值辅助字段，可以异步检查。
• 大批量导入可以使用临时表，清洗合格后再进入正式表。
• 高频日志可以弱化字段约束，但规范事件仍应有版本和来源标识。

如果为了吞吐量取消关键唯一约束，就必须测算重复数据清理、对账和客服处理的长期成本。很多团队只测写入 TPS，没有把异常修复的人力和业务损失算进总成本，最终得出了偏向短期性能的错误结论。

4. 如果系统需要频繁迭代、字段变化很快

变化频繁的系统可以减少僵化的数据库枚举和复杂检查约束，但核心身份、金额、租户隔离和权限边界仍不能因为灵活性而放弃。灵活字段应有版本、来源和校验策略，不能简单把所有内容塞进 JSON 后就认为问题消失。

一种较稳妥的做法是：稳定字段使用明确类型和约束，变化字段放入扩展结构，但为扩展结构保留 schema 版本、来源、更新时间和关键字段索引。对于进入报表和核心流程的扩展字段，应在使用前完成规范化，不要让每个下游使用者各自解释。

5. 如果团队数据库运维能力有限

不要选择团队完全没有故障处理经验、迁移经验和监控能力的方案，只因为它在理论上更先进。数据库能力最终要通过备份恢复、变更发布、慢查询处理、锁冲突排查和数据修复体现出来。

团队能力有限时，优先选择运行行为可预测、资料和工具成熟、自动化迁移路径清晰的方案。宁可先把核心业务做成强约束的简单结构，也不要引入复杂架构后再靠人工脚本维护一致性。

十一、我在表结构评审中使用的一张检查清单

1. 先检查字段定义是否表达了真实业务含义

• 字段名称是否能区分创建时间、业务发生时间和同步时间？
• 金额是否包含币种、精度和舍入规则？
• 状态字段是否有版本、字典或状态机定义？
• 空值、空字符串和默认值是否各自有明确含义？
• 是否把多个业务概念压缩在一个字段中？
• 是否存在用字符串存储日期、金额或布尔值的历史包袱？

字段命名只是表面问题，真正要检查的是字段能否支持后续查询、统计、审计和迁移。如果一个字段需要在每个报表里通过复杂条件解释，它的定义大概率不够稳定。

2. 再检查唯一性和并发行为

• 主键是否只是物理标识，业务唯一键是否单独存在？
• 唯一范围是否需要包含租户、组织、渠道或业务日期？
• 重试请求是否能通过幂等键识别？
• 唯一冲突发生时，应用是否能返回确定的业务结果？
• 高并发下是否测试过同时创建和同时更新？
• 软删除和归档是否影响唯一性判断？

我特别关注“先查后写”代码，因为它是重复数据的高发源头。只要业务上要求唯一，就应尽量让数据库承担最终判定，而不是相信一次查询结果能够代表未来几毫秒内的全部并发状态。

3. 最后检查约束变更和故障恢复

• 新增非空约束前，历史空值如何处理？
• 新增唯一索引前，重复记录由谁确认和合并？
• 增加外键前，孤儿记录如何清洗？
• 线上变更是否需要锁表，锁多久可以接受？
• 约束失败是否进入监控、日志和告警？
• 迁移中断后，是否能回滚到可用状态？
• 数据修复是否保留原值、修复人、修复时间和修复原因？

一张表如果只有建表 SQL，没有存量治理、变更策略和恢复方案，就还不能算完成设计。数据库表结构的生命周期至少包括设计、写入、读取、变更、归档和修复六个阶段。

4. 用评分卡替代“凭感觉选数据库”

权重不是固定答案。支付和账务系统可以提高约束与事务权重，日志系统可以提高写入和扩展权重，经营分析系统则应提高数据标准化、历史追溯和多源连接的权重。评分卡的价值不在于算出一个绝对分数，而在于把团队原本模糊的偏好变成可以讨论的依据。

十二、最终判断：选数据库，其实是在选择错误数据的处理方式

1. 强约束方案的优势和代价

强约束方案的最大优势是把错误拦截在数据入口，减少后续清洗和争议。它适合金额、账户、订单、库存、权限等高价值事实。约束失败通常是明确的，问题容易被监控，也更适合审计和追责。

代价是写入路径可能增加索引维护、锁竞争和迁移复杂度。历史数据不合规时，新增约束不能一键完成；分库分表后，部分约束也可能无法继续保持。团队需要为线上变更、冲突重试和异常修复准备能力。

2. 弱约束方案的优势和代价

弱约束方案通常在结构变化、写入吞吐和横向扩展方面更灵活，适合日志、原始事件、临时数据和部分内容型业务。它可以先接收数据，再由异步任务做清洗、标准化和质量评估。

但弱约束并不会让错误消失，而是把错误转移到应用、消息、数据治理和运维流程。只要缺少幂等、校验、对账和监控，系统最终会积累重复记录、无效引用和无法解释的历史数据。选择弱约束的前提是团队确实有能力承担这些工作。

3. 混合方案往往比二选一更现实

很多企业不需要在所有数据上采用同一种策略。可以把核心交易表放在强事务、强约束的关系型数据库中，把日志和原始事件放在更适合高吞吐和结构变化的存储中，再通过规范化数据层连接经营分析工具。

混合架构的关键是定义数据等级：

• 一级数据：账户、订单、支付、库存等会直接影响资金和履约，优先强约束和强审计。
• 二级数据：客户标签、业务画像和运营配置，允许一定灵活性，但要有版本和来源。
• 三级数据：日志、原始事件和临时分析数据，可以弱化关系约束，但必须保留事件 ID、来源和时间。

不同等级的数据采用不同校验策略，可以减少“所有表都强约束”带来的扩展压力，也避免“所有表都不约束”造成治理失控。

4. 下一步应该做什么

如果你正在设计新系统，建议马上做一次关键表评审，不必从所有表开始。先挑订单、客户、支付或库存这类高价值表，逐字段写清空值语义、类型、唯一范围、值域和关联关系。

如果你正在治理旧系统，不要直接给生产大表增加外键或唯一索引。先盘点写入入口，扫描历史异常，修复持续制造脏数据的代码和脚本，再通过灰度方式增加约束。

如果你正在做数据库选型，不要只提交吞吐量和成本对比。至少加入一组失败路径测试：并发重复写入、非法状态、边界金额、孤儿记录、批量导入、约束变更和事务回滚。真正能区分数据库方案的，往往不是它成功写入一条数据有多快，而是它能否可靠地拒绝错误数据，并让团队知道为什么拒绝。

我的最终建议可以浓缩成一句话：把稳定事实下沉到数据库，把复杂流程留给服务，把跨系统一致性交给消息和对账，再用数据分析验证这些责任是否真正落地。表结构设计不是建表语句的结束，而是数据质量、业务可靠性和未来迁移成本的起点。

CREATE TABLE order_item ( id BIGINT PRIMARY KEY, order_id BIGINT NOT NULL, sku_id BIGINT NOT NULL, quantity INT NOT NULL, unit_price DECIMAL(18,2) NOT NULL, CONSTRAINT ck_item_quantity CHECK (quantity > 0), CONSTRAINT ck_item_price CHECK (unit_price >= 0) );

免费注册

咨询方案

扫码咨询方案