union默认自动去重，原理是隐式执行distinct、逐列比对整行全等（含null视为相等），但要求各子查询列数相同、对应列类型兼容、顺序一致，列名以首个select为准。

UNION 本身就会去重，但要注意它对字段和类型的严格要求

UNION 默认去重，不需要额外加 DISTINCT；但它要求左右两个 SELECT 的列数必须一致、对应位置的列类型要兼容（如 INT 和 TEXT 就可能报错），且列名以第一个 SELECT 为准。如果字段顺序或类型不一致，即使逻辑上是同一类数据，也会导致语法错误或隐式转换失败。

• 确保每个 SELECT 返回相同数量的列，比如都选 3 列：SELECT id, name, created_at FROM users UNION SELECT user_id, nickname, reg_time FROM members
• 避免混用不兼容类型：比如左边是 DATE，右边是 VARCHAR，MySQL 可能强行转但 PostgreSQL 会直接拒绝；建议显式 CAST(created_at AS DATE)
• 别指望靠别名统一字段名——UNION 只认位置，SELECT id AS uid FROM t1 UNION SELECT pid AS uid FROM t2 中的 uid 别名不会影响匹配，第二列仍需与第一列类型/长度可比

UNION ALL 不去重，性能更好但不符合“去重复记录”需求

如果你真想删掉跨表结果里的重复行，就绝不能用 UNION ALL。它只是拼接，零去重逻辑，执行快是因为跳过了排序+比较环节。很多同学误以为“加了 ALL 就更强大”，其实这里恰恰相反——你要的是去重，UNION ALL 直接绕过这一步。

• UNION 底层会把结果集合并后做 DISTINCT（通常通过临时排序或哈希），所以有明显开销；但这是必要代价
• 如果两张表本身就无交集（比如按时间分区的订单表），且你 100% 确认没重复，才考虑 UNION ALL 来提速
• 别为了“看起来快”而用 UNION ALL 再套一层 SELECT DISTINCT —— 这样写既冗余又更慢，因为先拼再扫全量

跨表去重失败？大概率是 NULL 值或空字符串处理不一致

SQL 标准中，NULL = NULL 返回 UNKNOWN，不是 TRUE，但 UNION 去重时会把两个 NULL 视为相等。问题常出在：一张表用 NULL 表示未填，另一张用空字符串 ''，它们在 UNION 中不被视为重复。

• 检查是否混用了 NULL 和 ''：用 COALESCE(name, '') 或 NULLIF(name, '') 统一归一化
• 大小写敏感性也会影响：PostgreSQL 默认区分大小写，'Alice' 和 'alice' 不会被去重；可用 LOWER(name) 统一处理
• 多余空格同样干扰：TRIM(full_name) 比直接 full_name 更稳妥

大数据量下 UNION 去重变慢？优先检查索引和字段裁剪

UNION 去重本质是合并后全字段比较，如果 SELECT 出太多列（尤其是 TEXT/BLOB 类型），不仅传输慢，内存排序也容易爆。这不是语法问题，而是执行计划层面的瓶颈。

• 只 SELECT 真正需要的字段，别写 SELECT * —— 即使两表结构一样，* 也会把所有列拉进来参与去重计算
• 如果只是校验主键是否重复，可以先 SELECT id FROM t1 UNION SELECT id FROM t2，比带整行数据快得多
• 确保被 SELECT 的字段上有索引（尤其用于 WHERE 的条件列），否则子查询阶段就可能全表扫描，拖垮整体

实际去重逻辑远比“写个 UNION 就完事”复杂，关键是理解它对比的是**每一行的完整字段组合**，而不是某一个 ID 或 name。字段对齐、NULL 处理、类型隐式转换，三者漏掉任何一个，都可能让“看似去重”变成“漏重”或“报错”。