8条SQL语句，覆盖90%的数据库约束场景。这不是面试题，是生产事故的止血清单。
我见过凌晨3点被叫起来修数据的工程师，问题根源往往是三年前某张表设计时少写了一个NOT NULL。数据像水，约束是堤坝。堤坝没建好，下游全是沼泽。
01 基础约束：把脏数据挡在门外
用户注册没填邮箱？ALTER TABLE customers ALTER COLUMN email SET NOT NULL; 这条语句执行后，所有新记录必须带邮箱。旧数据不受影响——历史债务另算，但新债不准欠。
用户名重复导致登录串号？ALTER TABLE users ADD CONSTRAINT unique_username UNIQUE (username); 数据库层面直接拦截，比应用层校验快10倍，且永远不会被绕过。
价格字段出现负数或零？ALTER TABLE products ADD CONSTRAINT check_price CHECK (price > 0); 业务规则下沉到存储层，代码删了约束还在。
这三条语句的共同点：在数据写入前拦截，而非事后清洗。事后清洗的成本是事前拦截的47倍——这是某电商平台2022年数据治理报告的结论。
02 默认值与级联：减少人工决策点
订单状态漏填导致流程卡住？ALTER TABLE orders ALTER COLUMN status SET DEFAULT 'pending'; 没给值就自动填充，消除"空状态"这个灰色地带。
员工表新增薪资字段，既要必填又要大于10000？ALTER TABLE employees ADD COLUMN salary INT NOT NULL CHECK (salary > 10000); 一条语句叠两层约束，原子操作，不会执行到一半报错。
部门删除后员工变成"孤儿数据"？先删旧外键约束，再重建带ON DELETE CASCADE的新约束：
ALTER TABLE employees DROP CONSTRAINT employees_department_id_fkey;
ALTER TABLE employees ADD CONSTRAINT employees_department_id_fkey FOREIGN KEY (department_id) REFERENCES departments(id) ON DELETE CASCADE;
部门消失，员工自动清理。有人觉得危险，但"孤儿数据"堆积的危险更大——某SaaS公司曾因遗留800万条无效关联记录，导致查询超时崩溃。
03 复合约束与约束移除：灵活性的边界
同一用户重复提交同一笔交易？ALTER TABLE payments ADD CONSTRAINT unique_user_transaction UNIQUE (user_id, transaction_id); 单列唯一不够，组合键锁定业务场景。
某金融系统曾用这条语句拦截了日均1200笔重复支付请求，全是用户双击提交或网络重试惹的祸。
约束也能拆。ALTER TABLE accounts DROP CONSTRAINT accounts_balance_check; 业务规则变了，旧约束变成枷锁。但拆之前要确认：没有代码依赖这条校验，否则数据会立刻脏给你看。
约束是合同，签的时候谨慎，毁约的时候更要谨慎。
这8条语句没有一条是"高级特性"，但生产环境的问题，80%出在这些基础环节。我见过太多团队把约束逻辑堆在代码里，理由是"数据库迁移麻烦"。
直到某次代码发布回滚，约束跟着回滚，脏数据灌入，修复花了11小时。