MySQL CHECK 中使用 NOW 为什么建表失败

MySQL 的 CHECK 表达式不允许使用 NOW() 这类非确定函数，因此 CHECK (closes_at > NOW()) 会在定义约束时失败。修复方向是把当前时间判断放到业务写入逻辑或查询条件中；CHECK 留给行内字段之间的固定关系，例如 closes_at > opens_at。

这不是给 NOW() 换一种拼写就能解决的问题。还需要先决定业务要求：是写入时必须未过期、查询时只返回有效记录，还是数据库中所有记录永远不能过期？三个目标对应的实现方式不同。

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

下面基于 MySQL 8.4 文档解释现有能力限制，不把它当作某次新发布的变更。SQL 为供读者在独立测试库使用的原创示例，没有实际运行截图或输出。

先把 NOW 从 CHECK 中移出来

先给出一份可表达时间区间关系的表结构。两个时间字段都明确非空，CHECK 只要求关闭时间晚于开启时间，不引用系统当前时刻。

-- 在独立测试库建表，名称已存在时应另选测试名称
CREATE TABLE offer_window_demo (
  id BIGINT PRIMARY KEY,
  opens_at DATETIME NOT NULL,
  closes_at DATETIME NOT NULL,
  CONSTRAINT offer_window_order CHECK (closes_at > opens_at)
);

-- 读取实际定义，确认约束只引用这两个字段
SHOW CREATE TABLE offer_window_demo;

这个约束保证的是区间顺序。一个已经结束的历史区间仍然可能完全符合它；如果业务允许留存历史记录，这通常正是需要的存储规则。

反过来，下面是用来说明建表失败原因的候选定义，不应作为生产方案执行。即使表没有数据，表达式含有不允许的函数也会使定义被拒绝。

-- 反例：NOW 是非确定函数，不能放入 CHECK 表达式
CREATE TABLE offer_bad_demo (
  id BIGINT PRIMARY KEY,
  closes_at DATETIME NOT NULL,
  CONSTRAINT offer_bad_future CHECK (closes_at > NOW())
);

为什么语句内不变仍不代表确定函数

NOW() 在同一条语句中采用语句开始时的时间值，但在不同时间执行语句时，返回值会变化。语句内部稳定与 CHECK 所要求的确定性不是同一个判断。

MySQL 官方规则允许符合要求的确定性内置函数与运算符，明确将 NOW() 列为不符合确定性要求的例子。因而这里应调整规则放置的位置，而不是把建表失败解释成时间字段格式有误。

从业务角度也能看出差别：即便一行数据写入时截止时间在未来，时间自然流逝后它仍会到期。CHECK 不会成为随时钟运行、自动重新检查整张表的计时服务。将“记录永远不过期”作为行约束，会掩盖真正需要设计的状态查询或过期处理。

固定行内关系与当前有效状态分开写

固定区间采用前面的 CHECK。查询时要找当前有效记录，则把当前时间写在 WHERE 条件里。下面使用左闭右开的区间：开启时刻算有效，关闭时刻不再有效。

-- 当前状态由查询时刻决定，不能用写入时的结论永久代替
SELECT id, opens_at, closes_at
FROM offer_window_demo
WHERE opens_at  NOW()
ORDER BY closes_at, id;

此处 NOW() 用于查询，不属于 CHECK 定义。DATETIME 示例需要应用和会话约定一致的时间含义；如果团队统一使用 UTC，应在写入值和查询基准上保持一致，不能一侧按本地时间、另一侧按 UTC 比较。

如果要求“创建时提交的截止时间必须晚于提交基准”，则应在写入服务中明确校验该条件，失败时拒绝请求。为了说明这种写入语义，也可以在测试场景采用条件插入：

-- 条件插入仅示意本次写入判断，不能替代所有写入入口的统一控制
INSERT INTO offer_window_demo (id, opens_at, closes_at)
SELECT 902, NOW(), '2035-01-01 00:00:00'
WHERE '2035-01-01 00:00:00' > NOW();

示例中的日期是固定测试值，不代表永久有效的生产参数。条件不成立时不会插入行，调用方需要根据受影响行数区分拒绝与成功；主键冲突等数据库错误则应单独处理。其他 INSERT、UPDATE 入口仍需要相同业务规则，不能因为有这一条语句就宣称所有数据都经过当前时间校验。

旧建表脚本迁移时要保留什么

迁移时先保存原始 DDL 和失败信息，分清旧规则到底在保护什么。若旧需求只是“结束时间晚于开始时间”，改成行内比较即可；若旧需求是“只展示未过期记录”，应同步修改读路径。

不要直接删除原有的其他 CHECK 或修改已有时间数据来让 DDL 看似成功。对于已有表，新增行内约束前还应评估存量区间是否满足它，并准备相应的业务修复方案。本文最小例子是新建测试表，不提供未知生产表的直接改写命令。

最小示例的结果判断与相关问题

在独立测试对象中，可以用一组明确固定的区间判断约束的含义。有效例子可插入，逆序区间应被 CHECK 拒绝；这里描述的是预期规则，不是伪造的本机输出。

-- 固定区间用于判断行内关系，不依赖执行当天的时钟
INSERT INTO offer_window_demo (id, opens_at, closes_at)
VALUES (901, '2030-06-01 09:00:00', '2030-06-01 10:00:00');

-- 反例：截止早于开启，应被 offer_window_order 拒绝
INSERT INTO offer_window_demo (id, opens_at, closes_at)
VALUES (903, '2030-06-01 10:00:00', '2030-06-01 09:00:00');

换成 CURRENT_TIMESTAMP 就可以吗？

不能靠同义名称解决。CURRENT_TIMESTAMP 是 NOW 的同义形式；应根据业务目标移动判断位置。

把 NOW 包在自定义函数里可行吗？

不应这样处理。CHECK 不允许存储函数；包装也没有消除当前时间依赖。

写入时检查通过，以后会自动变成不符合约束吗？

前面的有效区间约束只比较存储字段，不随时钟改变。是否过期应由查询时刻或单独的状态处理机制判断，而不是等待 CHECK 自动改变记录状态。

官方参考：CHECK 表达式限制、日期时间函数。