UNION默认自动去重，原理是隐式执行DISTINCT、逐列比对整行全等（含NULL视为相等），但要求各子查询列数相同、对应列类型兼容、顺序一致，列名以首个SELECT为准。
UNION 本身就会去重，但要注意它对字段和类型的严格要求
UNION 默认去重，不需要额外加 DISTINCT；但它要求左右两个 SELECT 的列数必须一致、对应位置的列类型要兼容（如 INT 和 TEXT 就可能报错），且列名以第一个 SELECT 为准。如果字段顺序或类型不一致，即使逻辑上是同一类数据，也会导致语法错误或隐式转换失败。
- 确保每个
SELECT返回相同数量的列，比如都选 3 列：SELECT id, name, created_at FROM usersUNIONSELECT user_id, nickname, reg_time FROM members - 避免混用不兼容类型：比如左边是
DATE，右边是VARCHAR，MySQL 可能强行转但 PostgreSQL 会直接拒绝；建议显式CAST(created_at AS DATE) - 别指望靠别名统一字段名——
UNION只认位置，SELECT id AS uid FROM t1UNIONSELECT 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 t1UNIONSELECT id FROM t2，比带整行数据快得多 - 确保被 SELECT 的字段上有索引（尤其用于 WHERE 的条件列），否则子查询阶段就可能全表扫描，拖垮整体
