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在唯一索引里的自由穿梭，或者外键缺失索引导致的隐式全表扫描。