EXISTS相关子查询需正确关联外层字段并排除自身行，如WHERE u2.email = u1.email AND u2.id != u1.id；漏关联或未排除自匹配将导致逻辑错误；索引优化和UNIQUE约束优先于手写校验。
相关子查询怎么写才能检查某字段是否重复
直接用 EXISTS 配合外层表的字段引用是最稳妥的方式。比如想确认 users 表中 email 字段在当前行之外是否还存在相同值，就得让子查询“看到”当前行的 email 值，并查其他行有没有撞车。
常见错误是漏掉关联条件，导致子查询变成独立执行，结果恒为真或恒为假；或者误用 = 而不是 != 或主键排除，造成自匹配（自己和自己比，永远相等）。
- 子查询里必须包含对外部表字段的引用，例如
WHERE u2.email = u1.email AND u2.id != u1.id - 一定要排除当前行本身，否则每条记录都会被判定为“有重复”
- 如果外层表没有主键（比如临时结果集），可用
ROW_NUMBER()或组合唯一字段代替id
UPDATE 场景下怎么避免破坏唯一性
在更新某行的 email 时，不能只查原值是否重复，还要确保新值不与其他行冲突。这时相关子查询得同时约束“新值”和“非本行”两个条件。
典型错误是把新值硬编码进子查询，或忘记过滤掉正被更新的那条记录，导致 UPDATE 直接失败或逻辑出错。
- 用
WHERE email = NEW.email AND id != OLD.id（触发器中）或WHERE email = ? AND id != ?（应用层参数化） - 如果 UPDATE 同时改多个字段且需联合唯一校验，子查询 WHERE 条件要同步覆盖所有列
- 注意 NULL 处理：SQL 中
NULL = NULL为 false，若字段允许 NULL，需额外判断(email IS NULL) = (NEW.email IS NULL)并分别处理
性能差？别让相关子查询全表扫
相关子查询本质是对外层每一行都执行一次内层查询，如果外层数据量大、又没索引，速度会断崖式下降。这不是语法问题，而是执行计划失控。
很多人试了几次发现慢就放弃相关子查询，其实只要加对索引，它完全可以跑得比 JOIN 还快——尤其当外层只查少量行时。
- 确保子查询中用于关联和过滤的字段都有索引，例如
(email, id)复合索引 - 避免在子查询 WHERE 中对字段做函数操作，如
LOWER(email)，会导致索引失效 - 用
EXPLAIN看执行计划，确认子查询是否走了索引扫描（type: ref或range），而不是ALL
替代方案：UNIQUE 约束比手写子查询更可靠
相关子查询适合动态校验或复杂业务规则，但单纯防字段重复，数据库原生的 UNIQUE 约束才是首选。它由存储引擎保证原子性、并发安全，且无需你操心执行路径。
有人觉得“加约束太死板”，结果在应用层反复补子查询，反而引入竞态条件（比如两次请求几乎同时通过校验再插入）。
-
ALTER TABLE users ADD CONSTRAINT uk_email UNIQUE (email);是最简方案 - 需要忽略 NULL 的唯一性？部分数据库支持
FILTERED INDEX（SQL Server）或PARTIAL INDEX（PostgreSQL） - 真要动态控制（如“仅对 status=1 的记录唯一”），才值得上相关子查询 + 触发器或应用层双检
相关子查询的边界很容易模糊——它不该承担约束职责，而应聚焦于“在约束之外补充逻辑”。一旦开始为唯一性写多层嵌套子查询，先停下来问问：这真的是数据库该管的事吗？
