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