MySQL 8.4 CHECK 约束为什么没拦住脏数据：启用状态、隐式转换与写入复核

MySQL 8.4 的 CHECK 约束可以在写入时拒绝不满足条件的行，但看到“脏数据已经进表”并不一定说明约束失效。最常见的原因是约束仍处于非强制状态、表达式遇到 NULL 后得到未知结果，或者输入值先经过了与预期不同的类型转换。排查时要把约束定义、边界写入和历史数据扫描放在同一条证据链里。

先用 SHOW CREATE TABLE 确认约束确实处于 enforced 状态，再分别测试 TRUE、FALSE、NULL 和类型边界；CHECK 约束只负责判断新写入，不会自动清理历史脏数据。

很多人刚用上MySQL 8.4的CHECK约束，明明按业务规则写好了校验逻辑，结果不合规的脏数据还是直接写进表没被拦住，这类问题绝大多数情况都能顺着下面的调试清单定位到根因。

明明配置了CHECK约束却拦不住非法写入，核心原因基本集中在三点：约束没有真正启用、数据隐式转换改变了原有的判断逻辑、上线前后没覆盖全量写入路径做复核。

先复现一个“约束没拦住”的现场

假设订单表要求金额不能小于零，直觉写法如下：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  amount DECIMAL(10, 2),
  CONSTRAINT chk_orders_amount CHECK (amount >= 0)
);

测试校验逻辑的时候别只插一个负数就完事，至少准备一个合法值、一个明显非法值和一个空值，并记录每次写入的实际结果：

INSERT INTO orders VALUES (1, 12.50); -- 应通过
INSERT INTO orders VALUES (2, -1.00); -- 应拒绝
INSERT INTO orders VALUES (3, NULL);  -- 需要单独判断 NULL 语义

如果第二条没有报错，先停在数据库侧核对表定义，而不是立刻修改应用代码。约束名称、表达式和 enforced 状态都可能与迁移文件不一致。

用 SHOW CREATE TABLE 确认约束真的在工作

迁移脚本返回执行成功，不等于目标实例上的最终定义就是预期版本，第一时间先查看完整建表语句确认：

SHOW CREATE TABLE orders\G

重点看三件事：约束表达式是否还是 amount >= 0，约束是否带有非强制状态，以及当前连接访问的是否真是目标库。不要只用客户端的可视化结构面板判断，因为面板可能隐藏约束属性或缓存旧结构。

如果是从旧版本升级或由迁移工具创建，建议把 SHOW CREATE TABLE 的结果保存到发布验收记录。对于新加约束，先执行历史数据扫描，再决定是否切换到强制校验；否则上线动作可能直接撞上已有坏数据。

把 TRUE、FALSE、NULL 三条路径分开

CHECK 表达式不是简单的“结果等于真才通过”。使用可空列时，比较表达式遇到 NULL 会得到未知结果，这与明确的 FALSE 不是一回事。若业务要求金额必须存在，约束应同时写出非空条件：

CREATE TABLE payments (
  id BIGINT PRIMARY KEY,
  amount DECIMAL(10, 2) NOT NULL,
  CONSTRAINT chk_payments_amount CHECK (amount >= 0)
);

如果暂时不能把列改成 NOT NULL，也要把非空语义写进表达式并用三组数据验证。测试报告中明确记录“通过”“拒绝”还是“得到未知结果”，这样才不会把 NULL 路径误判成约束被绕过。

SELECT amount, amount >= 0 AS check_result
FROM orders
WHERE id IN (1, 2, 3);

检查数字和字符串比较的隐式转换

约束表达式两侧的数据类型决定了比较方式。列是字符类型却拿来保存金额时，空字符串、带空格的数字或混合字符可能触发转换警告、截断或与预期不同的比较结果。不要用一条“看起来合理”的 SQL 代替实际边界测试。

CREATE TABLE import_rows (
  id BIGINT PRIMARY KEY,
  score_text VARCHAR(32),
  CONSTRAINT chk_import_score CHECK (score_text >= '0')
);

SHOW WARNINGS;
SELECT id, score_text, score_text >= '0' AS check_result
FROM import_rows;

更稳妥的做法是让列使用业务类型，例如金额使用定点数、日期使用日期类型；若必须接收文本，先在导入层把空白、非法字符和范围错误分流，再把规范化结果写入受约束列。约束是最后一道边界，不应承担全部清洗职责。

上线前先找出历史脏数据

后来新增的 CHECK 约束不会替你修复过去已经写入的行，上线前应使用与约束完全相同的业务条件扫描旧表：

SELECT id, amount
FROM orders
WHERE amount 

找到异常数据后，先判断来源是旧接口、批量导入还是人工误操作，再选择补值、隔离或删除。不要为了让迁移通过而直接把异常行改成零，这会掩盖真实业务含义，后续出问题走审计也无法溯源。

覆盖 INSERT、UPDATE 和批量导入三种写入路径

很多反馈“约束没生效”的场景，开发者只验证了手工 INSERT，却没有走真正的业务写入路径做校验。建议把以下用例加入回归清单：

1. INSERT 合法值与非法值，确认结果分别通过和拒绝。
2. UPDATE 把已有合法值改成非法值，确认同样被拒绝。
3. 批量导入准备一条坏记录，确认失败范围、错误日志和已写入行符合事务约定。
4. 用真实连接池或 ORM 跑一次，确认应用没有吞掉约束错误。

每次验收都保留执行 SQL、错误信息、表定义摘要和数据前后计数。这样当问题再次出现时，可以迅速区分数据库规则、数据类型和应用写入路径。

常见问题：CHECK 约束排查怎么做

为什么负数插入成功了？

先确认连接的数据库、表名和约束定义，再看约束是否处于强制状态；如果表达式包含可空字段，还要分别测试 NULL 和明确负数。

把列改成 NOT NULL 就够了吗？

不够。NOT NULL 只能排除空值，范围、格式和业务关系仍需要 CHECK 或其他数据校验规则。

增加约束后历史数据会自动被修复吗？

没必要直接跳过约束上线，先用同一表达式扫描旧数据，完成清理和复核后，再把约束纳入正式发布。

把约束验收结果留在迁移记录里

CHECK 约束是否可靠，最终不取决于建表语句写得多漂亮，而取决于现场是否能证明它处于正确状态、对边界值有确定反应、对历史数据有清理方案。把 SHOW CREATE TABLE、四类边界写入和数据前后计数放进迁移验收记录，下一次升级或切换导入工具时就有可复用的证据。