数据库设计 数据完整性 学会数据库约束的正确写法，掌握数据库约束怎么写

数据库设计 | 数据完整性：学会数据库约束的正确写法，掌握数据库约束怎么写

2025年8月最新动态：随着AI驱动的自动化数据库优化工具兴起，数据完整性的重要性被重新强调，近期某大型电商平台因缺失外键约束导致订单与用户数据脱节，造成数百万损失，再次证明合理的数据库约束设计仍是系统稳定的基石。

为什么约束是你的数据库"守门员"

想象一下：财务系统里出现负数库存、用户表里躺着几百个同名同姓的"张三"、订单关联的客户ID根本不存在...这些灾难场景，90%都能用数据库约束提前拦截。

约束的本质是给数据立规矩，它的核心优势：

• 提前扼杀脏数据：在插入时就拒绝不符合规则的数据
• 节省应用层代码：不用在Java/Python里重复写校验逻辑
• 自文档化：看到约束就知道这个字段的合法范围

五大核心约束实战写法

NOT NULL：杜绝"空指针"噩梦

-- 用户注册时手机号必填
CREATE TABLE users (
    user_id INT PRIMARY KEY,
    phone VARCHAR(20) NOT NULL  -- 插入null会直接报错
);

常见坑：字段允许NULL时，要特别处理 WHERE phone=NULL（要用IS NULL）

UNIQUE：防重名神器

-- 防止员工工号重复
CREATE TABLE employees (
    emp_id INT PRIMARY KEY,
    emp_code VARCHAR(10) UNIQUE,  -- 像身份证号这种
    name VARCHAR(50)
);

特殊技巧：对多字段联合唯一 UNIQUE (dept_id, emp_name)

PRIMARY KEY：数据身份证

-- 自增主键标准写法（MySQL）
CREATE TABLE orders (
    order_id INT AUTO_INCREMENT PRIMARY KEY,  -- 自动+1且不可重复
    order_date DATETIME NOT NULL
);

注意：主键默认自带NOT NULL + UNIQUE双重特性

FOREIGN KEY：表关系的"结婚证"

-- 确保订单属于真实存在的用户
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    user_id INT,
    FOREIGN KEY (user_id) REFERENCES users(user_id)
        ON DELETE CASCADE  -- 用户删除时同步删订单
);

级联操作选项：

• ON DELETE CASCADE：主表删记录，从表跟着删
• ON UPDATE SET NULL：主表改ID，从表设NULL

CHECK：自定义验证规则

-- 保证商品价格合理
CREATE TABLE products (
    product_id INT PRIMARY KEY,
    price DECIMAL(10,2) CHECK (price > 0),
    stock INT CHECK (stock >= 0)
);

高级用法：支持正则表达式（如验证邮箱格式）

约束组合使用技巧

场景：一个电商SKU表需要：

1. 非空货号
2. 货号前缀必须为"SKU-"开头
3. 同店铺下货号不能重复

CREATE TABLE product_skus (
    sku_id VARCHAR(20) NOT NULL,
    shop_id INT NOT NULL,
    CHECK (sku_id LIKE 'SKU-%'),
    PRIMARY KEY (sku_id),
    UNIQUE (shop_id, sku_id),
    FOREIGN KEY (shop_id) REFERENCES shops(shop_id)
);

避坑指南

1. 性能权衡：外键约束会影响写入速度，高频写入表可考虑应用层校验
2. 命名规范：给约束起名方便后续维护

   CONSTRAINT fk_order_user FOREIGN KEY (user_id) REFERENCES users(user_id)

3. 延迟检查：大批量导入数据时可临时禁用约束

   SET FOREIGN_KEY_CHECKS = 0;  -- MySQL语法

最佳实践路线图

1. 设计阶段：用工具绘制ER图时同步标注约束
2. 开发阶段：先加约束再写业务代码
3. 测试阶段：专门设计违反约束的测试用例
4. 运维阶段：监控约束违规日志（如MySQL的SHOW ENGINE INNODB STATUS）

终极心法：把约束看作数据模型的"法律条文"——制定时越严谨，运行时越省心。