mysql SQL执行流程中的数据完整性与约束处理

约束检查分阶段穿插进行：非空约束在值解析后、写入前检查；主键和唯一键冲突在行写入前触发；外键检查由 InnoDB 实时校验，MyISAM 忽略；MySQL 不支持延迟约束，所有检查均在语句执行后立即进行。

SQL 执行时约束检查发生在哪个阶段

MySQL 在 INSERT、UPDATE、DELETE 语句执行过程中，** 约束检查不是一次性在最后做，而是分阶段穿插进行 **。主键（PRIMARY KEY）和唯一键（UNIQUE）冲突检查通常在“行写入前”触发；外键（FOREIGN KEY）检查则依赖存储引擎——InnoDB 会在语句执行期间实时校验，而 MyISAM 直接忽略外键约束。

常见错误现象：ERROR 1062 (23000): Duplicate entry 'xxx' for key 'PRIMARY' 或 ERROR 1452 (23000): Cannot add or update a child row，都说明约束已在语句执行中途被拒绝，事务会回滚到语句级保存点（如果启用了 innodb_locks_unsafe_for_binlog 等特殊配置则可能不同）。

• 非空约束（NOT NULL）检查在解析完值、准备写入前发生，早于主键 / 唯一检查
• 检查顺序受列定义顺序影响不大，但受索引结构影响：联合唯一索引要求整组值同时满足唯一性
• SET sql_mode = 'STRICT_TRANS_TABLES'能确保所有约束失败都报错；否则某些模式下（如ALLOW_INVALID_DATES）可能静默截断或转为默认值

外键约束如何影响 UPDATE/DELETE 性能与锁行为

InnoDB 中外键操作会自动加锁并触发额外查询，这是容易被低估的性能开销来源。例如对父表执行 UPDATE 主键值，不仅会锁住该行，还会对子表中所有匹配的外键行加S（共享）锁——即使你只改一个字段，也可能导致子表全表扫描（若子表外键列无索引）。

典型陷阱：ALTER TABLE child_table ADD CONSTRAINT fk_parent_id FOREIGN KEY (parent_id) REFERENCES parent(id) 执行成功，但没给 child_table.parent_id 建索引，后续任何 DELETE FROM parent WHERE id = ? 都会触发子表全表扫描 + 行锁，拖慢整个事务。

• 外键列必须有索引（单列或作为最左前缀），否则 InnoDB 拒绝创建外键（5.7+ 版本会报错 ERROR 1822 (HY000)）
• ON DELETE CASCADE看似方便，但大表级联删除可能长时间持 有锁，且不记录单条日志，不利于 binlog 回放定位问题
• 批量 INSERT INTO …… SELECT 含外键引用时，约束检查按行逐条进行，无法向普通 INSERT 那样用 bulk insert buffer 优化

延迟约束（DEFERRABLE）在 MySQL 中不存在

MySQL** 不支持 SQL 标准中的延迟约束（DEFERRABLE INITIALLY DEFERRED）**。这意味着你无法把约束检查推迟到事务提交时才做——所有约束都在每条 DML 语句执行完毕后立即验证。这个限制直接影响复杂业务逻辑的设计方式。

比如想先插入子记录、再插入父记录（反向依赖），或在一个事务中交换两张表的主键值，MySQL 天然不支持。常见变通做法是临时禁用约束检查，但必须极度谨慎：

• SET FOREIGN_KEY_CHECKS = 0 只跳过外键检查，不影响主键 / 唯一 / 非空等其他约束
• 该设置是会话级的，不会影响其他连接，但若在存储过程中使用，需确保异常路径也能恢复为1
• 禁用后执行的非法数据（如孤立子记录）不会报错，但后续开启检查时也不会自动修复——它只影响“新写入”，不校验存量数据

SET FOREIGN_KEY_CHECKS = 0; INSERT INTO child (id, parent_id) VALUES (1, 999); -- 此时不报错，即使 parent_id=999 不存在 INSERT INTO parent (id) VALUES (999); SET FOREIGN_KEY_CHECKS = 1;

唯一索引 NULL 值处理与“伪重复”问题

MySQL 中唯一索引（UNIQUE）对 NULL 值的处理是：** 多个 NULL 被视为互不相等 **。这常导致“看起来重复却通过校验”的情况，尤其在业务逻辑误将 NULL 当默认值时。

例如：CREATE TABLE user (email VARCHAR(255), UNIQUE(email))，允许插入多条 email IS NULL 的记录。但应用层若把未填 邮箱 统一设为NULL，就可能积累大量“空邮箱用户”，后续想补全时才发现违反唯一性。

• 如果业务上 NULL 和空字符串 '' 语义相同，应在应用或触发器中统一转为''，并让字段NOT NULL DEFAULT ''
• 复合唯一索引中只要有一个列为NULL，整行即不参与重复判断（标准 SQL 行为，MySQL 严格遵循）
• 使用 INSERT …… ON DUPLICATE KEY UPDATE 时，若冲突键含 NULL，不会触发UPDATE 分支，因为 NULL = NULL 为UNKNOWN，不构成“重复键匹配”

约束不是执行流程末端的“验收关卡”，而是嵌在解析、优化、执行各环节里的主动拦截器。真正难处理的从来不是报错本身，而是那些没报错却埋下数据歧义的场景——比如 NULL 在唯一索引里的自由穿梭，或者外键缺失索引导致的隐式全表扫描。