比较 NOT ENFORCED 与 ENFORCED 的迁移步骤并处理存量脏数据

把已有 MySQL 表上的 CHECK 约束从 NOT ENFORCED 切到 ENFORCED，关键不是把一条 DDL 直接改写，而是先确认约束状态，再找出已经存在的违规行，最后安排切换。这样做的好处是约束定义可以先进入表结构，业务有时间清理历史数据，真正启用时也能把失败范围控制在迁移窗口内。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/create-table-check-constraints.html

最稳妥的路径是“先定义、后扫描、再修复或隔离、最后启用”。NOT ENFORCED 不会替历史数据自动补检；切换到 ENFORCED 前，必须把会让表达式返回 FALSE 的存量行处理掉。

先确认两种状态的差异

MySQL 的 CHECK 约束语法允许在定义后追加 ENFORCED 或 NOT ENFORCED。省略执行子句时默认执行；写成 NOT ENFORCED 时，约束仍然会出现在表定义中，但不会拦截插入、更新等写入。

例如订单金额必须大于零，可以先把约束挂到表上：

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    amount DECIMAL(10, 2) NOT NULL,
    status VARCHAR(20) NOT NULL,
    -- 先保存规则，给历史数据迁移留出准备时间
    CONSTRAINT ck_orders_amount_positive CHECK (amount > 0) NOT ENFORCED
);

这一步适合“先统一表结构、后安排数据治理”的迁移。它不等于已经完成校验：历史上的负数或零仍可能存在，后续写入也不会因为这条约束而失败。

切换到 ENFORCED 后，CHECK 表达式如果对新写入或更新结果为 FALSE，相应操作会产生约束违规。需要注意，TRUE 和 UNKNOWN 的判断还涉及 NULL 的三值逻辑，所以不要只凭字段名猜测边界。

先把约束名称和当前状态查清楚

迁移脚本不要假设约束名一定是 MySQL 自动生成的 表名_chk_1。显式命名更容易审计；已有表则应先从元数据读取真实名称和执行状态。

SELECT
    tc.CONSTRAINT_NAME,
    tc.TABLE_NAME,
    tc.ENFORCED,
    cc.CHECK_CLAUSE
FROM information_schema.TABLE_CONSTRAINTS AS tc
LEFT JOIN information_schema.CHECK_CONSTRAINTS AS cc
    ON cc.CONSTRAINT_SCHEMA = tc.CONSTRAINT_SCHEMA
   AND cc.CONSTRAINT_NAME = tc.CONSTRAINT_NAME
WHERE tc.CONSTRAINT_SCHEMA = DATABASE()
  AND tc.TABLE_NAME = 'orders'
  AND tc.CONSTRAINT_TYPE = 'CHECK';
-- 用元数据确认约束名、表达式和 ENFORCED 状态，避免切错对象

也可以用 SHOW CREATE TABLE orders 查看完整表定义。元数据查询更适合写入迁移记录，因为它能直接留下 ENFORCED=YES 或 NO 的状态。

把 CHECK 表达式改写成存量扫描条件

下一步不是立刻执行 DDL，而是把约束表达式转换成“需要处理”的查询。示例约束是 amount > 0，因此明显违规的数据是小于等于零的行：

SELECT id, amount, status
FROM orders
WHERE amount  0 返回 FALSE 的存量行

SELECT COUNT(*) AS invalid_rows
FROM orders
WHERE amount 

如果原始约束允许可空字段，扫描条件必须把业务上不接受的 NULL 单独写出来。例如 CHECK (amount > 0) 遇到 NULL 时结果可能是 UNKNOWN，而不是 FALSE；要把 NULL 也视为脏数据，就使用 amount IS NULL OR amount ，或者补上独立的 NOT NULL 约束。

复杂表达式也遵循同一原则：逐项列出“表达式为 FALSE”的输入，不要简单地把整个表达式前面加一个 NOT 就结束。NULL、隐式类型转换和 SQL mode 都可能让结果与直觉不同。

修复和隔离要分开做决定

查到违规行后，通常有三种处理方式：能由业务规则确定正确值时修复；暂时无法判断时先隔离；如果违规行本来就是合法的历史例外，就先不要启用这条约束。不要为了让 DDL 通过而批量填一个没有业务依据的默认值。

如果选择先隔离，可以把待处理行复制到专用表，再由业务确认是否删除原表记录。下面的示例只展示迁移关系，实际删除前要配合备份、审计和回滚方案：

CREATE TABLE orders_quarantine LIKE orders;

INSERT INTO orders_quarantine
SELECT *
FROM orders
WHERE amount 

如果是修复而不是隔离，建议按主键分批处理，并在每批之后重新执行同一条扫描查询。修复动作要明确写进迁移记录：是更正金额、补齐字段，还是把记录转入其他业务状态。数据库约束只能判断条件，不会替你决定业务上的正确值。

确认没有违规后再切到 ENFORCED

MySQL 支持直接改变现有 CHECK 约束的执行状态。约束名必须使用前一步查到的真实名称：

ALTER TABLE orders
    ALTER CHECK ck_orders_amount_positive ENFORCED;
-- 只有确认存量行满足 amount > 0 后，才启用持续拦截

如果还有存量行违反条件，启用操作会失败，表不会被部分切换。这个失败是有价值的保护信号：回到扫描查询处理剩余数据，而不是反复重试相同的 DDL。

启用后，可以再次查询状态并用一个故意违规的事务测试写入边界。生产环境不要用无回滚保护的测试数据：

SELECT CONSTRAINT_NAME, ENFORCED
FROM information_schema.TABLE_CONSTRAINTS
WHERE CONSTRAINT_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders'
  AND CONSTRAINT_NAME = 'ck_orders_amount_positive';
-- 迁移记录应看到 ENFORCED=YES

START TRANSACTION;
INSERT INTO orders (id, amount, status)
VALUES (900001, 0, 'test');
-- 这个值用于确认约束边界，生产测试时应准备回滚策略
ROLLBACK;

把迁移拆成可观察的几个阶段

实际项目可以把状态拆成“定义已发布、扫描进行中、违规行已处理、约束已启用”四个阶段，并为每个阶段保存表名、约束名、表达式、违规行数量和执行时间。这样即使迁移由多个发布窗口完成，也能判断当前数据库究竟处在哪一步。

这个流程的价值不在于让迁移看起来复杂，而在于把“表结构变更”和“历史数据治理”拆开。前者由 MySQL 执行，后者需要业务确认；两者混在一条发布命令里，失败时很难判断到底是表达式、脏数据还是锁等待造成的。

相关问题

NOT ENFORCED 会不会自动检查旧数据？

不会把它当成已经完成的全表校验。它主要用于保留约束定义并暂不执行，旧数据是否合规仍要由迁移脚本按表达式主动扫描。

为什么扫描不到 NULL，但启用后仍需要处理 NULL？

比较表达式遇到 NULL 可能得到 UNKNOWN。如果业务要求字段非空，应显式使用 NOT NULL 或在扫描条件中加入 IS NULL，不要把 UNKNOWN 当成 FALSE。

启用失败后要不要删除 CHECK 约束？

通常不需要。保留 NOT ENFORCED 定义可以让后续写入继续沿用同一规则，处理剩余违规行后再重新执行启用；只有规则本身已经改变，才应重新评估约束定义。