外键约束失效需主动验证：用LEFT JOIN + IS NULL查子表中foreign_key_column值在父表不存在的记录，避免NOT IN（含NULL时结果为空），示例为SELECT child.id, child.order_id FROM orders child LEFT JOIN customers parent ON child.customer_id = parent.id WHERE parent.id IS NULL。
检查外键约束是否被违反
外键约束失效通常不会立即报错，而是在插入或更新时才触发。要主动验证，得手动查出那些 foreign_key_column 的值在父表中不存在的记录。
- 用
LEFT JOIN+IS NULL最直观：先左连接主表和被引用表，再筛选出右表匹配为空的行 - 避免用
NOT IN，因为只要被查列含NULL，整个结果就全为空——这是常见坑 - 示例：
SELECT child.id, child.order_id FROM orders child LEFT JOIN customers parent ON child.customer_id = parent.id WHERE parent.id IS NULL;
查找违反唯一约束的重复值
唯一索引或 UNIQUE 约束被绕过（比如建表后手动插入、或禁用了约束），会导致数据层面实际重复。不能只信 DDL，得查数据本身。
- 用
GROUP BY+HAVING COUNT(*) > 1定位重复字段组合 - 若检查复合唯一键，
GROUP BY后必须包含所有参与列，顺序无关但缺一不可 - 注意：空值（
NULL）在 SQL 中不等于任何值（包括另一个NULL），所以UNIQUE列允许多个NULL；但如果你业务上认为它们应视为“相同”，就得额外加IS NULL判断
验证 CHECK 约束逻辑是否被绕过
CHECK 约束在某些数据库（如 MySQL 5.7 及更早）只是语法保留，实际不生效；即使生效，历史数据也可能在约束添加前就已违规。
- 直接写 WHERE 条件模拟约束表达式，例如约束是
age >= 0 AND age ，就查WHERE age 150 - 别忽略类型隐式转换带来的偏差：比如字符串字段定义了
CHECK (status IN ('active','inactive'))，但实际存了'ACTIVE '（带空格）或'Active'（大小写不同）——这属于数据质量而非约束问题，但常被误判为约束失效 - PostgreSQL 支持
pg_constraint元数据查询约束定义，MySQL 则需查INFORMATION_SCHEMA.CHECK_CONSTRAINTS（8.0.16+）
确认 NOT NULL 字段是否存在空值
显式声明 NOT NULL 是最基础的完整性保障，但迁移、批量导入或应用层绕过 ORM 都可能导致空值悄悄混入。
-
WHERE column IS NULL是唯一可靠方式；= NULL永远不成立，这是 SQL 三值逻辑的硬规则 - 对可为空的字段做统计时，
COUNT(column)自动忽略NULL，而COUNT(*)统计所有行——这个差异常被用来快速发现异常比例 - 如果字段类型是
TEXT或VARCHAR，还要留意空字符串''和NULL的语义区别：前者是有效值，后者才是违反NOT NULL
实际执行这类校验时，最容易被忽略的是时间窗口问题：查询跑完到应用写入之间存在间隙，结果只能反映快照状态。更关键的是，很多约束（尤其是外键）在分布式写入或分库分表场景下，根本无法靠单库 SQL 保证——那已经不是查询能解决的事了。
