SQL 约束是数据库管理系统里最容易被初学者忽略、却又最值得花时间吃透的一块内容。它的作用不是让 SQL 语句“跑得更快”而是从表结构层面把数据规则焊死防止业务写入脏数据。简单说约束就是数据库在帮你做数据校验哪些字段必须给值、哪些字段不能重复、一张表怎么唯一标识一条记录、两张表之间的引用关系怎么维护、字段的取值范围怎么限制。这篇文章会围绕约束的完整体系展开从五种核心约束的语法讲起配全套可复现的建表和测试语句再把约束维护、性能影响和常见坑一起梳理掉。无论你是在准备数据库面试还是刚接手一个老项目的表结构这篇文章都值得直接收藏。Neso Academy 的数据库课程一直以“概念准、例子多”著称它把约束单独拿出来讲并不是为了凑章节。约束在数据库管理系统里的地位相当于面向对象语言里类型系统的地位编译期能拦住的问题不要拖到运行期再报错。SQL 约束也一样能由数据库拦住的非法数据不要在应用层再去写一堆 if-else。读完后你会得到一个非常直接的能力拿到任何一张业务表能看懂它的约束设计意图需要设计新表时能自然地把业务规则落到 DDL 里而不是写一段到处打补丁的校验逻辑。1. 核心能力速览能力项说明约束类型NOT NULL、UNIQUE、PRIMARY KEY、FOREIGN KEY、CHECK、DEFAULT主要作用保证数据完整性、一致性、合法性和表间引用关系的正确性定义方式CREATE TABLE 内联定义、表级定义、ALTER TABLE 后添加适用数据库MySQL、MariaDB、PostgreSQL、SQL Server、Oracle、SQLite 等主流关系型数据库是否需要单独安装否属于 SQL 标准 DDL 能力数据库自带是否支持批量管理支持可通过 ALTER TABLE、脚本化 DDL、迁移工具统一管理学习门槛需要具备基础建表、插入、更新操作能力适合场景数据模型设计、接口开发、数据迁移、数据仓库建模、面试复习约束不是某个数据库特有的功能而是整个关系型数据库管理系统的通用设计。只要你的项目用了 MySQL、PostgreSQL 或者 SQL Server约束规则基本一致语法稍有差异但核心思维完全相同。2. 适用场景与使用边界约束适合用在所有需要保证数据质量的业务场景中。用户表手机号字段必须唯一用 UNIQUE用户 ID 必须全局唯一用 PRIMARY KEY。订单表订单金额不能为负数用 CHECK订单必须关联一个真实存在的用户用 FOREIGN KEY。商品表库存数量不能低于零用 CHECK商品编码不能为空用 NOT NULL。字典表类型名称不能重复用 UNIQUE 或复合唯一约束。日志表业务主键可能不是单字段用复合主键或复合唯一索引。但约束也有边界。约束擅长的是结构化规则不适合做复杂业务校验比如“该用户是否是 VIP 会员且累计消费满 1000 元”这种跨表跨状态的逻辑就不应该拆成一堆 CHECK 约束硬塞进数据库。过度设计约束会带来三个问题一是建表语句变得极度冗长二是批量导入数据时频繁触发校验导致性能下降三是业务规则变化时修改约束成本高。正确的做法是基础数据完整性交给约束复杂业务流程校验交给应用层或者存储过程。从合规和安全角度看约束还有一个容易被忽视的作用它是防止 SQL 注入攻击后的“最后一道闸”。如果应用层被注入了恶意 SQL 并尝试写入非法数据约束可以拦截一部分明显违规的操作例如插入超长字符串、写入重复主键、破坏外键关系等。但注意约束永远不能替代参数化查询也不能替代权限管理。数据库设计和安全防护是两个层面的工作约束只是数据完整性的兜底。3. 环境准备与前置条件本篇文章的示例语句基于 SQL 标准语法兼容 MySQL 8.x 和大部分主流关系型数据库。建议准备一个本地测试环境。3.1 数据库选择如果机器上还没有数据库推荐按以下优先级安装数据库版本建议说明MySQL8.0 及以上轻量、常用、教程资源多MariaDB10.6 及以上与 MySQL 高度兼容PostgreSQL14 及以上标准支持 CHECK、外键等功能完善SQLite3.x零配置适合快速验证约束语法SQL Server2019 及以上企业场景常用对于本文示例MySQL 8.0 是最省心的选择。如果你只装了 SQLite也可以通过命令行直接执行 SQL 语句约束逻辑是一样的。3.2 创建测试数据库CREATE DATABASE IF NOT EXISTS constraint_demo DEFAULT CHARACTER SET utf8mb4; USE constraint_demo;后续所有建表和测试语句都基于这个库。3.3 基础 DDL 能力准备约束定义是 DDLData Definition Language的一部分需要你对 CREATE TABLE 和 ALTER TABLE 有基本了解。不需要精通索引优化但需要知道主键会自带索引UNIQUE 也会生成唯一索引。4. 创建测试表与约束定义没有任何约束的建表语句只是一张能存数据的“容器”而加上约束之后这张容器才真正具备业务含义。从一个用户表和订单表开始。4.1 创建用户表包含 NOT NULL、UNIQUE、PRIMARY KEY、CHECK、DEFAULTCREATE TABLE users ( id INT NOT NULL AUTO_INCREMENT COMMENT 用户ID主键, username VARCHAR(50) NOT NULL COMMENT 用户名不能为空, phone VARCHAR(20) UNIQUE COMMENT 手机号必须唯一, email VARCHAR(100) NOT NULL UNIQUE COMMENT 邮箱非空且唯一, age TINYINT NOT NULL DEFAULT 0 COMMENT 年龄默认0, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1启用 0禁用, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), CONSTRAINT chk_users_age CHECK (age 0 AND age 120), CONSTRAINT chk_users_status CHECK (status IN (0, 1)) ) ENGINEInnoDB COMMENT用户表;这张表已经覆盖了五类约束中的大部分约束类型约束字段作用PRIMARY KEYid主键非空且唯一NOT NULLusername, email, age, status, created_at字段不允许为空UNIQUEphone, email字段值必须唯一DEFAULTage, status, created_at不显式赋值时使用默认值CHECKage, status年龄范围、状态取值校验4.2 创建订单表包含复合主键和外键约束CREATE TABLE orders ( order_id INT NOT NULL COMMENT 订单ID, user_id INT NOT NULL COMMENT 用户ID, product_name VARCHAR(100) NOT NULL COMMENT 商品名称, amount DECIMAL(10,2) NOT NULL COMMENT 订单金额, order_date DATE NOT NULL DEFAULT (CURRENT_DATE) COMMENT 下单日期, PRIMARY KEY (order_id, user_id), CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(id) ) ENGINEInnoDB COMMENT订单表;PRIMARY KEY (order_id, user_id)表示这是一个复合主键即 order_id 和 user_id 的组合必须唯一。外键约束fk_orders_user保证了订单表中的 user_id 必须在 users 表存在如果插入不存在的用户数据库直接拒绝。5. 功能测试与效果验证约束写没写对不能只看建表是否成功要看非法数据是否能被拦截。下面针对每种约束做一组完整测试。5.1 NOT NULL 约束测试测试目的验证非空字段不允许插入 NULL。-- 正常插入 INSERT INTO users (username, email) VALUES (zhangsan, zhangsantest.com); -- 违反 NOT NULL 约束username 为空 INSERT INTO users (username, email) VALUES (NULL, nullnametest.com);预期结果第二条语句执行失败报错信息类似Column username cannot be null判断标准只要数据库拒绝了第二条插入且第一条插入成功NOT NULL 约束就生效了。5.2 UNIQUE 约束测试测试目的验证同一字段不允许重复值。-- 插入一条电话数据 INSERT INTO users (username, phone, email) VALUES (lisi, 13800000000, lisitest.com); -- 重复 phone INSERT INTO users (username, phone, email) VALUES (wangwu, 13800000000, wangwutest.com); -- 重复 email INSERT INTO users (username, phone, email) VALUES (zhaoliu, 13900000000, zhangsantest.com);预期结果后面两条都会失败分别报 duplicate entry for key phone 和 duplicate entry for key email。唯一约束和业务上的“每人只能注册一次手机号”完全对应。5.3 PRIMARY KEY 约束测试测试目的验证主键非空且唯一同时观察 AUTO_INCREMENT 的行为。-- 显式插入主键 INSERT INTO users (id, username, email) VALUES (100, idtest100, idtest100test.com); -- 重复主键 INSERT INTO users (id, username, email) VALUES (100, idtest101, idtest101test.com); -- 不传主键依赖自增 INSERT INTO users (username, email) VALUES (noautoid, noautoidtest.com);预期结果第一条成功第二条因主键重复失败第三条成功且 id 自动生成。主键不仅保证唯一还会自动创建聚簇索引是查询最快的入口。5.4 FOREIGN KEY 约束测试测试目的验证外键是否能阻止无效的关联数据。-- 插入一个不存在于 users 表的 user_id INSERT INTO orders (order_id, user_id, product_name, amount) VALUES (1, 999, phone, 1999.00); -- 插入正常数据 INSERT INTO orders (order_id, user_id, product_name, amount) VALUES (1, 1, phone, 1999.00);预期结果第一条失败报错信息类似Cannot add or update a child row: a foreign key constraint fails第二条成功。外键的价值在于订单表不会出现“用户已经删了订单还挂在库里”的孤儿数据。5.5 CHECK 约束测试测试目的验证取值范围和枚举值是否被限制。-- 年龄超出范围 INSERT INTO users (username, email, age) VALUES (oldman, oldmantest.com, 200); -- 状态非法 INSERT INTO users (username, email, status) VALUES (badstatus, badstatustest.com, 9); -- 正常数据 INSERT INTO users (username, email, age, status) VALUES (normal, normaltest.com, 25, 0);预期结果前两条失败第三条成功。注意 MySQL 8.0.16 之前 CHECK 约束会被解析但不会强制执行如果你在 5.7 上测试发现 CHECK 没生效这是版本问题。生产环境建议升级到 8.0.16 以上或者用触发器替代 CHECK。5.6 DEFAULT 约束测试测试目的验证未显式赋值时默认值是否正确填充。INSERT INTO users (username, email) VALUES (default_user, default_usertest.com); SELECT * FROM users WHERE username default_user;预期结果查询结果显示 age 为 0status 为 1created_at 为当前时间。默认值减少了应用层的赋值逻辑也让插入语句更简洁。5.7 复合主键测试测试目的验证复合主键唯一性的判定逻辑。-- 正常插入 INSERT INTO orders (order_id, user_id, product_name, amount) VALUES (2, 1, laptop, 4999.00); -- 同样的 order_id不同的 user_id允许插入 INSERT INTO orders (order_id, user_id, product_name, amount) VALUES (2, 2, laptop, 4999.00); -- 同样的 order_id 和 user_id拒绝插入 INSERT INTO orders (order_id, user_id, product_name, amount) VALUES (2, 2, tablet, 2999.00);预期结果前两条成功第三条失败。复合主键的判定不是看单个字段而是看所有主键字段的组合是否重复。6. 约束的维护与批量迁移实际开发中表结构很少一次设计到位。约束也需要动态维护。6.1 使用 ALTER TABLE 添加约束-- 为已有表添加 UNIQUE 约束 ALTER TABLE users ADD CONSTRAINT uk_users_idcard UNIQUE (idcard); -- 为已有表添加 CHECK 约束 ALTER TABLE users ADD CONSTRAINT chk_users_age_range CHECK (age 0 AND age 120); -- 为已有表添加默认值 ALTER TABLE users ALTER COLUMN status SET DEFAULT 1;注意 SQL Server 和 MySQL 的 ALTER COLUMN 语法略有差异上面第三条在 SQL Server 中更常见MySQL 用ALTER TABLE users ALTER COLUMN status SET DEFAULT 1;MySQL 实际上更推荐在 MODIFY COLUMN 中指定默认值ALTER TABLE users MODIFY COLUMN status TINYINT NOT NULL DEFAULT 1 COMMENT 状态;6.2 删除约束-- MySQL ALTER TABLE users DROP INDEX uk_users_idcard; ALTER TABLE users DROP CHECK chk_users_age_range; ALTER TABLE users DROP FOREIGN KEY fk_orders_user; -- SQL Server ALTER TABLE users DROP CONSTRAINT uk_users_idcard;删除外键前要确认没有视图或存储过程依赖它否则应用层可能直接报错。6.3 批量迁移数据时处理脏数据给已有大量数据的表添加约束最怕的是数据本身已经违规。正确顺序是先查询违反规则的数据。清洗或删除脏数据。再添加约束。例如要给 orders 表 amount 字段加 CHECK 约束但历史数据里已经有负数SELECT COUNT(*) FROM orders WHERE amount 0; -- 确认有脏数据后先更新 UPDATE orders SET amount 0 WHERE amount 0; -- 再添加约束 ALTER TABLE orders ADD CONSTRAINT chk_orders_amount CHECK (amount 0);批量导入场景中可以临时关闭外键检查来提升导入速度但导入完成后必须重新开启SET FOREIGN_KEY_CHECKS 0; -- 执行批量导入 SET FOREIGN_KEY_CHECKS 1;注意这个开关只在当前会话有效不要在生产环境长期关闭。关闭期间如果有非法外键写入后续数据一致性会非常难修。7. 约束对性能与数据完整性的影响很多开发者担心约束影响性能但这种担心需要拆开看。7.1 索引和约束的关系PRIMARY KEY 和 UNIQUE 约束会自动创建索引这是约束提升查询性能的部分。例如 users 表的 phone 字段有 UNIQUE 约束按 phone 查询时可以直接走索引不需要额外建索引。FOREIGN KEY 约束则需要注意如果外键字段本身没有索引某些数据库如 MySQL在删除父表记录时会全表扫描子表来检查是否有引用记录性能开销明显。建议为外键字段手动创建索引CREATE INDEX idx_orders_user_id ON orders(user_id);7.2 CHECK 约束的性能开销CHECK 约束的开销很小它只做字段级数值判断几乎可以忽略不计。相比于在应用层写一堆校验逻辑数据库做这个动作更快因为数据在内存中不需要网络传输到应用层再返回。7.3 批量操作时的性能观察批量 INSERT 时每个约束都会被执行一次。UNIQUE 约束需要检查唯一性FOREIGN KEY 需要检查父表是否存在高并发批量写入时确实会拉低吞吐量。可以这样优化使用批量 INSERT 语句减少事务提交次数。临时关闭和开启外键检查。建立合适的索引让唯一性和外键检查走索引而不是全表扫描。观察约束对性能影响最直接的方法是执行 EXPLAINEXPLAIN SELECT * FROM orders WHERE user_id 1;通过执行计划确认是否使用了索引逐步判断约束对查询路径的影响。8. 常见问题与排查方法问题现象可能原因排查方式解决方案插入数据报 “Column cannot be null”NOT NULL 约束触发查看报错字段检查 INSERT 语句是否遗漏字段补全必填字段或用 DEFAULT 值插入重复值报 “Duplicate entry”UNIQUE 或 PRIMARY KEY 约束触发SELECT 查询已存在的数据确认重复字段改用 UPDATE 或清洗数据后重试插入关联数据报外键失败FOREIGN KEY 指向的父表记录不存在查询父表确认关联 ID 是否存在先插入父表记录或检查引用 ID 是否正确删除父表记录报外键限制子表仍有引用记录或外键 ON DELETE 策略未配置查询子表引用记录先删除子表记录或在建表时指定 ON DELETE CASCADE / SET NULLCHECK 约束没生效MySQL 8.0.16 以下版本检查数据库版本升级版本或用触发器代替给已有数据表加约束失败表内已有数据违反约束先执行违反规则的数据查询清洗数据后再添加约束批量导入数据极慢外键检查、唯一性检查频繁触发关注磁盘 I/O 和 SQL 执行时间临时关闭 FOREIGN_KEY_CHECKS导入后恢复约束重名导致建表失败同一 Schema 下约束名重复查询 information_schema 中的约束名使用独立且有意义的约束名排查约束问题时最实用的统一入口是查询 information_schemaSELECT TABLE_NAME, CONSTRAINT_NAME, CONSTRAINT_TYPE FROM information_schema.TABLE_CONSTRAINTS WHERE TABLE_SCHEMA constraint_demo;这条 SQL 能一次性列出当前库所有约束快速确认约束是否创建成功。9. 最佳实践与使用建议9.1 命名规范约束名要一眼能看出用途。推荐格式主键PK_表名唯一UK_表名_字段名外键FK_表名_字段名检查CHK_表名_字段名默认DF_表名_字段名例如CONSTRAINT pk_users_id PRIMARY KEY (id), CONSTRAINT uk_users_phone UNIQUE (phone), CONSTRAINT fk_orders_user_id FOREIGN KEY (user_id) REFERENCES users(id), CONSTRAINT chk_users_age CHECK (age 0)可读性强的约束名排错时能省一半时间。9.2 约束和业务规则的分工数据库约束负责基础完整性应用层负责复杂业务规则。建议按这个优先级设计非空、唯一、主键、外键一律由数据库约束完成。字段取值范围、枚举状态用 CHECK 约束。跨表状态依赖、金额一致性、多步校验应用层事务处理。不要把业务规则全堆在数据库也不要完全放弃数据库约束。两者结合数据质量最稳。9.3 约束设计在产品迭代中的维护策略每张表上线前应该问三个问题哪些字段不允许为空哪些字段必须唯一哪些字段有固定的取值范围如果答案都清晰就把约束写进建表语句。后续业务发生变化时优先用 ALTER TABLE 调整而不是删表重建。生产环境的约束变更必须经过数据清洗、临时表验证、灰度执行三步。9.4 安全与合规提醒约束可以用来限制数据内容和引用关系但不会自动阻止 SQL 注入。开发者仍然需要使用参数化查询不能因为数据库有约束就放松对输入校验的警惕。涉及用户手机号、身份证号等敏感字段唯一约束要考虑脱敏存储和加密查询策略确保数据合规。10. 总结与下一步数据库管理系统里的 SQL 约束是投入产出比极高的知识模块。建表时多写几行约束就能在后续每一个插入、更新、删除操作里持续拦截非法数据。这篇文章覆盖了 NOT NULL、UNIQUE、PRIMARY KEY、FOREIGN KEY、CHECK、DEFAULT 六种约束的完整定义、建表语法、测试方法和常见坑。建议你现在做两件事。第一在本地数据库里把文中的 users 表和 orders 表建一遍逐条执行插入测试亲眼看到约束报错才算真正掌握。第二翻一下业务项目里现有的建表脚本看看哪些字段该加约束却漏掉了尝试用 ALTER TABLE 补上。下一阶段建议继续学习索引、事务隔离级别和存储过程。约束决定了“哪些数据能进来”索引决定了“进来的数据怎么快速找到”事务决定了“数据在并发场景下怎么保持一致”三者合在一起才算完整的数据治理体系。
