MySQL 8.4 CHECK 约束怎么落地：错误边界、迁移验收与回滚

订单表里出现负金额、未知状态，通常不是某一条接口突然失控，而是应用校验、脚本导入和后台修复各自维护了一套规则。MySQL 8.4 的 CHECK 约束可以把最基本的数据边界放回数据库，但上线前必须先处理存量脏数据，否则结构变更会在第一步就被旧记录挡住。

稳妥的落地顺序是：先找出违反规则的旧数据，再命名并添加 CHECK 约束，最后用一条合法写入和一条非法写入验证数据库是否真的接住了边界。

先把业务不变量写成数据库能判断的条件

以订单表为例，金额必须大于 0，状态只能取 pending、paid、shipped，而创建时间不能晚于约定的业务截止时间。它们都只依赖当前行，可以先写成三个约束：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  amount DECIMAL(12, 2) NOT NULL,
  status VARCHAR(16) NOT NULL,
  created_at DATETIME NOT NULL,
  CONSTRAINT chk_amount CHECK (amount > 0),
  CONSTRAINT chk_status CHECK (status IN ('pending', 'paid', 'shipped')),
  CONSTRAINT chk_time CHECK (created_at 

示例中的时间条件只是演示结构变更，生产规则应替换为不会随时间失效的列间关系，例如 paid_at IS NULL OR paid_at >= created_at。不要把需要查询其他表、访问外部服务或依赖当前时间函数的复杂业务判断硬塞进 CHECK。

添加之前先找存量脏数据

新约束只负责拦住后续写入，不能替你修复已经存在的记录。先用与约束完全一致的条件查询：

SELECT id, amount, status, created_at
FROM orders
WHERE amount  '2025-05-10 00:00:00';

把结果按来源分组比直接批量改值更安全：人工录入错误要回查订单凭证，未知状态要确认是否是旧版本留下的合法状态，时间异常要确认时区或导入批次。修复后再次运行同一查询，结果应为空，并把行数、修复脚本和审批记录放进迁移记录。

用稳定名称添加约束，保留可回退路径

存量检查通过后，再执行结构变更。每个约束都给出明确名称，后续排错时可以直接从错误信息定位规则：

ALTER TABLE orders
  ADD CONSTRAINT chk_amount CHECK (amount > 0),
  ADD CONSTRAINT chk_status CHECK (status IN ('pending', 'paid', 'shipped')),
  ADD CONSTRAINT chk_time CHECK (paid_at IS NULL OR paid_at >= created_at);

上线前先确认目标实例的 MySQL 版本、表上的并发写入和变更窗口。若迁移中途发现约束条件写错，回滚应针对约束名称，而不是删除整张表或覆盖整份建表语句：

ALTER TABLE orders DROP CONSTRAINT chk_time;

回滚只解除这一条数据库边界，不会恢复已经被错误脚本改过的数据，所以数据修复和结构回退要分别准备。

用合法与非法写入验收边界

先写入一条满足全部条件的记录，确认正常路径没有被误伤；再分别触发金额、状态和时间规则。非法写入应返回 CHECK 约束违规错误，且表中不应出现这条记录。

INSERT INTO orders (id, amount, status, created_at)
VALUES (108, 150.00, 'paid', '2025-05-09 10:30:00');

INSERT INTO orders (id, amount, status, created_at)
VALUES (109, -20.00, 'cancel', '2025-05-09 10:30:00');

检查点不要只看客户端是否弹错，还要查询主键、核对受影响行数，并用和应用不同的连接模拟脚本导入。这样才能证明边界在数据库层生效，而不是只在某个接口里生效。

常见误区：约束能保护什么，不能替代什么

CHECK 是最后一道数据边界，不是完整的领域模型。外键负责引用完整性，唯一索引负责重复值，事务和服务层负责跨行协作；把不同职责混在一个表达式里，既难迁移也难解释。

上线前的四项复查

1. 存量查询为空，且修复记录能追溯到具体批次。
2. 约束名称、表达式和应用校验文档一致。
3. 合法写入、非法写入、旁路写入都完成验证。
4. 保留按约束名称删除的回滚语句，并确认回滚不会掩盖已发生的数据变更。

如果表写入量很高，可以先在影子表或低流量副本上演练，再安排正式 ALTER TABLE。结构变更完成后，重新读取建表定义，并抽样检查历史数据，避免“迁移成功”只代表语句返回成功。

常见问题

CHECK 约束可以替代应用层校验吗？

不能。应用层可以给用户更友好的提示，CHECK 则保护所有写入入口；两层应共享同一套业务规则。

添加 CHECK 前为什么一定要查旧数据？

因为历史记录同样必须满足新约束。先查出并处理违规行，才能把结构变更和数据修复拆成可控步骤。

约束名称为什么不能省略？

稳定名称便于从报错定位具体规则，也便于只回滚一条约束、生成迁移审计记录。

复杂的跨表规则应该怎么保护？

按职责选择外键、唯一索引、事务或服务层校验；CHECK 只保留当前行能够独立判断的条件。