UNION ALL是纯流式拼接，无去重排序、不建临时表、不触发Using temporary或filesort；UNION强制“先拼再筛”，需建临时表、按第一列排序、全字段比对去重，性能开销显著更高。
UNION ALL 是纯流式拼接，UNION 则强制走“先拼再筛”流程，多出排序和去重两道硬开销。
UNION ALL 的执行路径：无中间态、不建表、不比较
它不做任何额外判断，就是把每个 SELECT 的结果按顺序推给上层。MySQL 不会创建临时表，也不触发 Using temporary 或 Using filesort。即使子查询用了 ORDER BY 或 LIMIT，只要没被外层包裹，就不会影响 UNION ALL 本身的执行结构。
- 各子查询独立执行，结果直接追加到输出缓冲区
- 字段类型不一致时直接报错
ERROR 1222，不会尝试隐式转换 - 如果某个子查询返回 0 行，不影响后续执行，也不改变整体性能曲线
UNION 的执行路径：必须建临时表 + 排序 + 全字段比对
UNION 实际等价于 (SELECT ... UNION ALL SELECT ...) DISTINCT，但这个 DISTINCT 不是轻量级过滤——它依赖排序实现去重，且排序默认按第一列升序。EXPLAIN 中一旦出现 Using temporary; Using filesort，就说明它正在干这三件事：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先把所有子查询结果写进内存或磁盘临时表（取决于
sort_buffer_size） - 对临时表按第一列排序（不管子查询里有没有写
ORDER BY） - 逐行扫描排序后结果，比较所有字段值（含
NULL、collation、长度截断）判定是否重复
这意味着：字段是 VARCHAR(10) 和 VARCHAR(50) 合并时，MySQL 按短的长度截断再比；'a ' 和 'a' 在 utf8mb4_general_ci 下可能被判为相同，但在 utf8mb4_bin 下不是。
为什么 ORDER BY 写在子查询里会被忽略？
因为 UNION 的语义决定了它只认外层的排序。写成 (SELECT a FROM t1 ORDER BY created_at LIMIT 10) UNION (SELECT a FROM t2) 是合法的，但这个 ORDER BY 只控制子查询内部输出顺序，对最终合并结果无影响。真正生效的排序必须放在整个 UNION 之后：... UNION ... ORDER BY id。否则 MySQL 就按第一列升序排，且这个行为无法关闭。
真正容易被忽略的是：UNION 的去重逻辑完全机械，它不理解业务含义。手机号带空格、时间字段精度不一致、大小写混用——这些都会让本该合并的行逃过去重，或者不该合并的被强行压成一条。
