MySQL CHECK 约束失败时怎么定位具体条件

MySQL 出现 CHECK 约束失败时，最快的定位方法不是盯着整条 SQL 猜，而是完成三次映射：从错误拿到约束名，从元数据拿到 CHECK 表达式，再把本次候选值代入每个子条件逐列计算。只要结果为 FALSE，当前行就会被拒绝；结果为 TRUE 或因 NULL 形成的 UNKNOWN，约束都视为通过。

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

先从报错里拿到约束名

假设订单表同时限制金额、折扣和状态。为约束显式命名后，错误日志中的约束名就能直接对应一条业务规则，比 MySQL 自动生成的 orders_chk_1 更适合排查。

-- 创建用于演示的订单表，每条 CHECK 都使用可读名称。
CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  amount DECIMAL(10,2) NOT NULL,
  discount DECIMAL(10,2),
  status VARCHAR(20) NOT NULL,
  -- 订单金额不能小于零。
  CONSTRAINT chk_amount_nonnegative CHECK (amount >= 0),
  -- 折扣可为空；非空时必须位于零到订单金额之间。
  CONSTRAINT chk_discount_range CHECK (
    discount IS NULL OR (discount >= 0 AND discount 

当写入的 amount=100、discount=120 时，失败对象是折扣范围而不是金额非负或状态集合。应用日志至少要保存约束名、表名和绑定参数；如果只记录“保存订单失败”，数据库已经给出的最重要线索就丢了。

反查数据库里真正生效的表达式

第一条命令应是 SHOW CREATE TABLE。它能看到列类型、空值属性、约束名以及 MySQL 规范化后的完整建表定义，适合确认应用认知与数据库现状是否一致。

-- 查看服务端保存的完整表定义，确认约束名和字段类型。
SHOW CREATE TABLE orders;

若日志已经给出 chk_discount_range，可以直接查询元数据表。必须同时限定数据库名；CHECK 约束名称在同一 schema 内要求唯一，而不同 schema 可以存在同名对象。

-- 通过报错中的约束名反查表名和 CHECK 表达式。
SELECT
  CONSTRAINT_SCHEMA,
  TABLE_NAME,
  CONSTRAINT_NAME,
  CHECK_CLAUSE
FROM information_schema.CHECK_CONSTRAINTS
WHERE CONSTRAINT_SCHEMA = DATABASE()
  AND CONSTRAINT_NAME = 'chk_discount_range';

如果应用连接可能跨库，不能依赖 DATABASE() 的偶然结果，应传入明确的 schema 名。若查询不到，依次检查：连接是否指向正确实例、当前账号是否能看到该对象、迁移是否已在本环境执行，以及错误是否来自另一套数据库。

把候选值代入条件逐列排查

拿到表达式后，不要马上修改约束。先把本次输入作为候选值放进一条 SELECT，把每个逻辑分支拆成独立列。这个查询只计算表达式，不写入数据，特别适合复现线上参数。

-- 设置本次失败请求中的候选值。
SET @amount = 100.00;
SET @discount = 120.00;

-- 分别计算空值分支、下界、上界和最终 CHECK 结果。
SELECT
  @amount AS amount,
  @discount AS discount,
  @discount IS NULL AS is_null_branch,
  @discount >= 0 AS lower_ok,
  @discount = 0 AND @discount 

这组值通常得到 is_null_branch=0、lower_ok=1、upper_ok=0、final_check=0。因此无需猜测“折扣约束有问题”，可以进一步确定为“折扣高于金额”。对于包含五六个条件的约束，也沿用同一方法：每个括号一列，最外层表达式再单独一列。

为什么 NULL 看起来绕过了条件

MySQL 对 CHECK 使用 SQL 三值逻辑。官方规则是：表达式为 TRUE 或 UNKNOWN 时通过，只有 FALSE 才违反约束。于是，下面这个看似能阻止负折扣的条件，并不能阻止 NULL：

-- discount 为 NULL 时，比较结果是 UNKNOWN，而不是 FALSE。
SELECT
  CAST(NULL AS DECIMAL(10,2)) >= 0 AS null_compare_result;

如果业务要求折扣必须存在，应在列上增加 NOT NULL，或在 CHECK 中显式写出 discount IS NOT NULL AND discount >= 0。两种写法的错误对象不同：前者表达列级必填，后者把“存在且非负”组合为一条业务规则。选择哪一种，应与数据模型语义一致，而不是为了让某条失败 SQL 临时通过。

结果与直觉不一致时检查类型转换

CHECK 表达式按照 MySQL 常规类型转换规则求值。候选数据来自字符串参数、JSON 提取结果或不同精度数值时，数据库实际比较的值可能不是应用日志里的文本形态。先用列的真实类型重建候选值，再计算条件：

-- 按目标列类型转换输入，观察数据库实际参与比较的数值。
SELECT
  CAST('100.00' AS DECIMAL(10,2)) AS amount_value,
  CAST('120.00' AS DECIMAL(10,2)) AS discount_value,
  CAST('120.00' AS DECIMAL(10,2))
    

还要核对当前 SQL 模式。官方文档指出，约束求值使用执行时的 SQL 模式；若表达式中的转换行为受 SQL 模式影响，不同连接设置可能产生不同结果。排查时应同时记录应用连接和手工复现连接的 @@sql_mode。

-- 对比应用连接与手工排查连接的 SQL 模式。
SELECT @@SESSION.sql_mode AS session_sql_mode;

批量更新失败时怎样缩小到具体行

单条 INSERT 有明确候选值，批量 UPDATE 则可能只有少数行在更新后违反约束。不要反复执行失败 UPDATE；先把更新后的表达式投影到 SELECT 中，找出会变成 FALSE 的行。以下示例假设要把折扣统一增加 20：

-- 预先计算更新后的折扣，并筛出最终 CHECK 为 FALSE 的行。
SELECT
  id,
  amount,
  discount,
  discount + 20 AS next_discount
FROM orders
WHERE NOT (
  discount + 20 IS NULL
  OR (
    discount + 20 >= 0
    AND discount + 20 

这里把 UPDATE 的新值表达式原样放入 SELECT，能够在不改变数据的前提下列出风险行。确认范围后，再决定是修正源数据、缩小更新条件，还是调整业务规则。不要用 UPDATE IGNORE 掩盖原因：官方文档说明，IGNORE 形式遇到 CHECK 为 FALSE 时会产生警告并跳过违规行，这很容易造成“部分成功”的数据状态。

修复时区分数据错误与约束错误

定位到具体分支后，修复方向只有两类。第一类是候选数据本身违背已确认的业务规则，例如折扣确实不能大于订单金额，此时应修正参数或上游计算。第二类是约束表达式没有准确表达业务，例如业务允许赠品折扣大于金额，却未把赠品状态纳入条件，此时才应通过评审后的 DDL 修改约束。

验证时准备三组最小样本：一条明确通过、一条明确失败、一条包含 NULL 的边界值。这样既能确认主体规则，也能确认 UNKNOWN 是否按预期处理。完成后把约束名、表达式、失败样本和修复决策写入变更记录，下一次日志能直接对应业务含义。

相关问题

错误里只有自动生成的 orders_chk_2，怎么知道是哪条规则

执行 SHOW CREATE TABLE orders 查看完整定义，或按 CONSTRAINT_SCHEMA 与 CONSTRAINT_NAME 查询 INFORMATION_SCHEMA.CHECK_CONSTRAINTS。查到 CHECK_CLAUSE 后再拆分计算，不要依赖约束序号猜测。

CHECK 表达式为 NULL 时为什么没有报错

因为 NULL 通常让布尔表达式得到 UNKNOWN，而 MySQL 的 CHECK 接受 TRUE 和 UNKNOWN，只拒绝 FALSE。若 NULL 也必须拒绝，需要增加 NOT NULL 或在表达式中显式判断 IS NOT NULL。

INSERT IGNORE 能不能作为临时修复

不建议。违规行会被跳过并产生警告，批量任务可能形成部分写入，后续更难判断哪些数据没有落库。应先用诊断 SELECT 找到失败行，再修正数据或规则。

为什么测试环境通过，生产环境却失败

优先比较两边的表定义、字段类型、约束是否 ENFORCED、应用传入值和会话 SQL 模式。只比较 SQL 文本不够，因为隐式转换和部署迁移差异都会改变实际求值结果。