异常教程

SQL CHECK 约束（手把手讲解）

更新时间:

💡一则或许对你有用的小广告

欢迎加入小哈的星球 ，你将获得：专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸：仿小红书（微服务架构）》 正在持续爆肝中，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...，点击查看项目介绍 ;
  • 《从零手撸：前后端分离博客项目（全栈开发）》 2 期已完结，演示链接： http://116.62.199.48/ ;

截止目前， 星球 内专栏累计输出 82w+ 字，讲解图 3441+ 张，还在持续爆肝中.. 后续还会上新更多项目，目标是将 Java 领域典型的项目都整一波，如秒杀系统, 在线商城, IM 即时通讯，权限管理，Spring Cloud Alibaba 微服务等等，已有 2900+ 小伙伴加入学习 ，欢迎点击围观

在数据库设计中，确保数据的完整性是开发者必须面对的核心问题之一。想象一下，如果一个电商平台的订单表中，允许用户输入负数的金额，或者将年龄字段设置为“1000岁”，这样的数据显然不符合现实逻辑。为了防止这种情况发生，SQL CHECK 约束应运而生。它就像数据库中的“质量检测员”，通过预定义的条件规则，自动过滤不符合规范的数据，从而保障数据的准确性和一致性。

SQL CHECK 约束的基本概念

数据完整性与约束的分类

在关系型数据库中，数据完整性通常分为四类：

  1. 实体完整性：通过主键约束确保每条记录唯一可识别。
  2. 域完整性：定义字段的数据类型、允许值范围等（如 CHECK 约束）。
  3. 参照完整性：通过外键约束保证关联表之间的数据一致性。
  4. 用户定义完整性：根据业务需求自定义规则，如 CHECK 约束的条件逻辑。

SQL CHECK 约束属于域完整性和用户定义完整性范畴，其核心作用是为表中的某一列或多个列设置条件表达式，只有满足条件的数据才能被插入或更新。

CHECK 约束的类比理解

我们可以将 CHECK 约束想象为“数据的安检通道”。例如，机场的安全检查会要求乘客携带的液体容器不超过100毫升，而 CHECK 约束则会限制某列的数值必须小于某个阈值。如果数据违反规则，就像安检时携带违禁品一样，会被直接拒绝通过。

语法结构与基本用法

在创建表时定义 CHECK 约束

CHECK 约束的语法相对直观，通常在 CREATE TABLE 语句中通过 CHECK (condition) 关键字实现。

示例1：限制年龄字段在合法范围内

CREATE TABLE users (  
    id INT PRIMARY KEY,  
    name VARCHAR(50),  
    age INT CHECK (age BETWEEN 0 AND 120),  
    email VARCHAR(100) UNIQUE  
);

在上述案例中，CHECK (age BETWEEN 0 AND 120) 确保了 age 列的值只能是0到120之间的整数。

在已有表中添加 CHECK 约束

如果表已经存在，可以通过 ALTER TABLE 语句动态添加约束：

ALTER TABLE users  
ADD CHECK (age BETWEEN 0 AND 120);

需要注意的是，某些数据库（如 MySQL）在添加 CHECK 约束时，可能不会实时校验现有数据，仅对后续操作生效。

多列联合条件的 CHECK 约束

CHECK 约束不仅限于单列，还可以跨多个列定义条件。例如，要求订单的总价必须等于商品单价乘以数量：

CREATE TABLE orders (  
    order_id INT PRIMARY KEY,  
    item_price DECIMAL(10,2),  
    quantity INT,  
    total_price DECIMAL(10,2),  
    CHECK (total_price = item_price * quantity)  
);

此时，如果尝试插入 item_price=100, quantity=2, total_price=200 是合法的，但若 total_price 设为190，则会被拒绝。

实际案例与代码示例

案例1：商品价格的正数验证

假设有一个电商系统的商品表，需要确保价格字段始终为正数：

CREATE TABLE products (  
    product_id INT PRIMARY KEY,  
    product_name VARCHAR(100),  
    price DECIMAL(10,2) CHECK (price > 0),  
    stock INT CHECK (stock >= 0)  
);

此时，若尝试插入 price = -10 的记录，会触发错误：

ERROR 1048 (23000): Column 'price' cannot be null

（注：不同数据库的报错信息可能略有差异，但核心是拒绝不符合条件的数据）

案例2：状态字段的枚举值限制

某些业务场景需要字段的取值属于预定义的集合，例如用户状态只能是 'active'、'inactive' 或 'pending'：

CREATE TABLE accounts (  
    account_id INT PRIMARY KEY,  
    status VARCHAR(10) CHECK (status IN ('active', 'inactive', 'pending'))  
);

当尝试插入 status = 'deleted' 时，系统会阻止该操作。

案例3：日期范围的约束

假设需要记录用户的注册时间，并且要求注册日期不能早于公司成立日期（例如2020-01-01）：

CREATE TABLE registrations (  
    reg_id INT PRIMARY KEY,  
    user_id INT,  
    registration_date DATE CHECK (registration_date >= '2020-01-01')  
);

此约束确保了所有注册记录的时间起点符合业务逻辑。

常见问题与最佳实践

问题1：如何处理多个 CHECK 约束的组合？

如果一个表需要多个 CHECK 条件，可以通过逻辑运算符 AND 或 OR 组合条件。例如：

CREATE TABLE employees (  
    emp_id INT PRIMARY KEY,  
    salary DECIMAL(10,2),  
    department VARCHAR(50),  
    CHECK (salary > 2000 AND department IN ('HR', 'Tech', 'Sales'))  
);

但需注意，条件复杂度过高可能导致维护困难，建议将相关约束拆分为多个独立的 CHECK 条件。

问题2：CHECK 约束是否会影响性能？

CHECK 约束的执行是在数据写入时实时校验的，因此频繁的复杂计算可能略微影响性能。例如，如果约束条件中包含复杂的函数调用或子查询，需要权衡数据安全性和性能开销。

最佳实践建议

  1. 保持条件简洁：避免在 CHECK 中使用复杂的表达式，优先使用基础算术和逻辑运算。
  2. 结合其他约束：与 NOT NULL、UNIQUE 等约束配合使用，形成多层数据保护。
  3. 文档化约束逻辑：在代码注释或数据库设计文档中说明 CHECK 约束的意图，方便团队协作。

CHECK 约束与其他约束的对比

以下表格总结了 CHECK 约束与其他常见约束的异同：

约束类型作用范围主要用途是否跨列支持
CHECK单列或多列自定义条件逻辑（如范围、枚举）是
NOT NULL单列确保字段值不为空否
UNIQUE单列或多列确保值的唯一性是
PRIMARY KEY单列或多列唯一标识记录并强制非空是
FOREIGN KEY单列或多列维护表与表之间的参照完整性是

高级用法与注意事项

注意事项1：默认值与 CHECK 约束的结合

如果字段有默认值，需确保默认值符合 CHECK 条件。例如：

CREATE TABLE payments (  
    payment_id INT PRIMARY KEY,  
    amount DECIMAL(10,2) DEFAULT 0 CHECK (amount >= 0)  
);

此时，amount 的默认值0是合法的，但如果默认值设为-50则会报错。

注意事项2：数据库兼容性

不同数据库对 CHECK 约束的支持存在差异：

  • MySQL：虽然支持语法，但默认不会校验现有数据，仅对新插入的数据生效。
  • PostgreSQL：完全支持 CHECK 约束，且会校验所有现有数据。
  • SQL Server：允许将约束标记为延迟检查（Deferred Checking）。

因此，在编写跨数据库的代码时，需提前测试兼容性。

结论

SQL CHECK 约束是数据库开发者手中一把灵活的“数据质量剪刀”，通过简单的条件规则，有效过滤不符合业务逻辑的数据。无论是限制年龄范围、验证价格正数，还是控制状态枚举，它都能提供直接且可靠的保障。

对于编程初学者，建议从单列约束开始实践，逐步过渡到多列联合条件的设计；中级开发者则可以探索与事务、索引等高级功能的结合。记住，合理的约束设计不仅减少后续的数据纠错成本，更是构建健壮系统的基石。

在未来的开发中，当遇到“数据意外值”或“业务逻辑漏洞”时，不妨先检查一下是否遗漏了某个 CHECK 约束——它可能就是解决问题的“最后一块拼图”。

最新发布

查看更多文章