MySQL 不同表使用同名 CHECK 约束为什么报错

MySQL 中，不同表使用同名 CHECK 约束仍可能报错，因为 CHECK 约束名必须在同一个 schema，也就是数据库内唯一。表名不同，并没有把 CHECK 名称分隔开。复制建表语句时只改表名、保留 CONSTRAINT 后的通用名称，是这一问题的常见触发方式。

修复时应给新表使用独立约束名，例如把 qty_nonnegative 改为 reserve_demo_qty_nonnegative。不要为了释放名称删除另一张表的有效约束，也不要把命名冲突当成数据不满足检查条件。

MySQL 官方地址：https://www.mysql.com/

本文依据 MySQL 8.4 的 CHECK 规则解释现有语义，按背景、旧写法、命名规则和迁移取舍展开，不将其描述成一次新版本变更。下面 SQL 为原创测试示例，没有伪造实际执行输出。

复制建表语句为什么会撞到约束名

假设需要建立库存表 stock_demo 与预留表 reserve_demo，两者都有数量字段 qty，也都要求数量非负。业务条件相同很合理，但约束标识不应直接照搬。

-- 在独立测试库执行；请先确认这些测试对象和约束名不存在
CREATE TABLE stock_demo (
  id BIGINT PRIMARY KEY,
  qty INT NOT NULL,
  CONSTRAINT qty_nonnegative CHECK (qty >= 0)
);

-- 故意保留同名约束来说明问题；这是预期失败的候选定义
CREATE TABLE reserve_demo (
  id BIGINT PRIMARY KEY,
  qty INT NOT NULL,
  CONSTRAINT qty_nonnegative CHECK (qty >= 0)
);

如果第一张表成功建立且同名约束仍存在，第二条语句在同一数据库内会遇到 CHECK 名称冲突。这个判断针对对象定义，不需要插入一行负数才能触发。客户端可能显示具体错误码和英文消息，应保留原始错误内容来区分失败类型。

也不要在脚本第一条失败后继续套用后续假设：例如 stock_demo 原本存在时，失败原因可能首先是表重名。定位时要看失败语句及当前库，而不是仅凭“建表失败”四个字判断。

把名称归属改成数据库范围来理解

可以把约束理解为“表上的业务条件”和“数据库内的标识”两部分。表达式 qty >= 0 作用于各自表中的 qty；名称 qty_nonnegative 则占用当前数据库的 CHECK 命名空间。

MySQL 按约束类型分别管理每个数据库内的命名空间。这里讨论的是 CHECK 与 CHECK 之间的重名，不应把它直接推广成所有索引、外键和 CHECK 都共用一个名称集合。跨数据库的同名 CHECK 也不属于本文所说的同一范围。

排查时可以先确认数据库，再查当前账号能够看到的约束元数据，找到名称实际属于哪张表。

-- 确认连接使用的数据库，避免把两个环境的对象混在一起
SELECT DATABASE();

-- 按类型和名称定位当前库内的 CHECK，权限影响可见元数据范围
SELECT CONSTRAINT_SCHEMA, TABLE_NAME, CONSTRAINT_NAME
FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
WHERE CONSTRAINT_SCHEMA = DATABASE()
  AND CONSTRAINT_TYPE = 'CHECK'
  AND CONSTRAINT_NAME = 'qty_nonnegative';

-- 读取所属测试表的完整定义，区分名称与实际表达式
SHOW CREATE TABLE stock_demo;

若查不到，应检查连接库、原始 SQL 是否显式限定其他库，以及账号是否能够查看相关对象。查询为空不能自动证明整个服务器没有这个名称，更不能据此随意删除或覆盖对象。

对比通用名称与带表前缀的定义

对尚未成功创建的 reserve_demo，只改它的候选建表语句即可。保留已成功建立的 stock_demo 约束，让两张表继续保持相同的非负数量要求。

-- 接续前文：第二张表尚未建立，仅为它换一个独立约束名
CREATE TABLE reserve_demo (
  id BIGINT PRIMARY KEY,
  qty INT NOT NULL,
  CONSTRAINT reserve_demo_qty_nonnegative CHECK (qty >= 0)
);

-- 查看服务器保存的实际约束名，便于后续维护脚本引用
SHOW CREATE TABLE reserve_demo;

如果两张表都还处于设计阶段，可以统一采用“表标识 + 字段或业务条件”的约定：stock_demo_qty_nonnegative 与 reserve_demo_qty_nonnegative。它们只是建议名称，不是 MySQL 强制格式。

显式命名便于迁移脚本稳定引用，但要求团队控制数据库内的名称唯一性。省略名称则由 MySQL 生成包含表名、_chk_ 与序号的名字；后续需要引用时，应读取实际定义，不猜测一定是某个序号。

-- 独立的另一种设计示例：省略显式名称，由服务器生成标识
CREATE TABLE inbound_demo (
  id BIGINT PRIMARY KEY,
  qty INT NOT NULL,
  CHECK (qty >= 0)
);

-- 使用实际定义中的名称，不把自动编号当成外部接口
SHOW CREATE TABLE inbound_demo;

迁移时同时更新正向和回退脚本

若错误发生在新增表的迁移，通常应先修正尚未执行成功的候选定义。让旧表保留原名称，可以减少对既有运维脚本的影响。修改模板时还要同步查找回退脚本中的 DROP CHECK 目标，避免正向创建新名称、回退仍引用旧名称。

名称修订与条件修订要分开记录。例如 qty_nonnegative 改成 reserve_demo_qty_nonnegative，只是标识变化；把 qty >= 0 改成 qty > 0 则改变了业务规则，不能顺手混入同一次命名修复。

如果已有生产对象确实需要统一名称，先保存完整表定义和依赖该名称的迁移、监控及回退配置，再单独制定 DDL。本文不建议为解决新表报错，先删除旧表约束，也不提供对未知生产表直接执行的替换命令。

采用命名约定前要分清的几个问题

把 CHECK 改成 NOT ENFORCED 能避免重名吗？

不能把它作为解决办法。NOT ENFORCED 控制是否执行条件检查，约束对象和名称仍然存在。这里需要处理的是标识冲突。

给名称加表前缀有什么限制？

CHECK 名称最多64个字符。长表名与长业务描述拼接前应规划缩写，避免简单截断后重新产生冲突。大小写变体也不适合作为团队区分业务对象的主要手段。

相同条件是否应该只留一个约束？

不同表各自的数据需要各自的约束。表达式可以相同，独立命名后仍分别约束各自表中的行；没有必要为了名称相同就取消其中一个条件。

建议把命名范围写进建表模板：同库内 CHECK 名唯一，标识包含表语义，回退使用实际名称。这样复制的是业务规则，而不是无意复用的数据库对象标识。

官方参考：MySQL CHECK 约束与命名空间说明。