union all 比 union 快因不执行去重和排序，直接拼接结果集；union 隐式添加 distinct 和临时排序，开销大，易成性能陷阱。
UNION ALL 为什么比 UNION 快
因为 UNION ALL 不去重，不排序，直接拼接结果集；UNION 会隐式加 DISTINCT 和临时排序，开销大得多。如果你确定两个查询结果没有重复，或者根本不在乎重复，就别用 UNION —— 这是性能陷阱最常发生的地方。
常见错误现象：SELECT * FROM t1 UNION SELECT * FROM t2 执行慢，但换 UNION ALL 瞬间变快；EXPLAIN 显示用了 Using temporary; Using filesort。
- 使用场景：日志表按月分表后汇总、多业务线数据归集、ETL 中的增量+全量合并
- 注意列数和类型必须严格一致，否则报错
ERROR 1222 (21000): The used SELECT statements have a different number of columns - 字符串长度差异会导致隐式截断（比如
VARCHAR(10)和VARCHAR(255)合并时，MySQL 以最长为准；但TEXT和VARCHAR混用可能触发警告）
列名和顺序怎么对齐才不出错
UNION ALL 只认位置，不认字段名。最终结果集的列名来自第一个 SELECT 子句，后面所有子句的列顺序、类型、数量都得跟它对齐。
容易踩的坑：第二个查询漏写一列、或把 created_at 和 updated_at 顺序写反，运行时不报错，但数据错位——这种 bug 很难肉眼发现。
- 建议显式写出字段名，别用
*：SELECT id, name, status FROM t1 UNION ALL SELECT id, title AS name, type AS status FROM t2 - 类型不兼容时 MySQL 会尝试隐式转换，比如
INT和VARCHAR拼一起，数值会被转成字符串再比较，可能导致索引失效 - 如果某张表缺字段，用
NULL AS xxx或'' AS xxx占位，确保结构一致
ORDER BY 和 LIMIT 怎么加才有效
UNION ALL 整体不支持直接在末尾写 ORDER BY 或 LIMIT，除非整个语句被括起来当子查询，或者只对最后一个子句生效（但通常不是你想要的）。
错误写法：(SELECT ...) UNION ALL (SELECT ...) ORDER BY id LIMIT 10 → 报错 ERROR 1221 (HY000): Incorrect usage of UNION and ORDER BY
- 正确做法：用括号包住整个
UNION ALL，再套一层查询：SELECT * FROM (SELECT ... UNION ALL SELECT ...) AS tmp ORDER BY id LIMIT 10 - 如果只想给某一部分排序，必须在那个
SELECT内部加ORDER BY+LIMIT，但要注意：子句里单独ORDER BY在UNION ALL中无意义，除非配合LIMIT做 Top-N 截断 - 大数据量下，外部
ORDER BY会导致全量合并后再排序，内存/磁盘压力陡增，考虑是否真需要全局排序
和 LEFT JOIN / CTE 比，什么时候该选 UNION ALL
它不是万能拼接工具。UNION ALL 是垂直堆叠（行追加），JOIN 是横向关联（列扩展），CTE 更适合逻辑复用或递归。选错会导致语义混乱或性能灾难。
典型误用：想把用户信息和对应订单数“拼”在一起，写了 SELECT u.* FROM users u UNION ALL SELECT COUNT(*) FROM orders → 列数不匹配，语义完全错乱。
- 该用
UNION ALL：多个独立数据源要合成一份扁平列表（如：各渠道广告点击日志、不同地区销售表） - 不该用：需要带关联条件、需要字段对齐映射、需要去重统计——这时候
JOIN或窗口函数更合适 - MySQL 8.0+ 支持 CTE，但
UNION ALL在低版本兼容性更好；不过 CTE 可读性高，嵌套深时优先考虑
真正麻烦的是跨字符集或 collation 不一致的表合并，比如一个表是 utf8mb4_0900_as_cs，另一个是 utf8mb4_general_ci，UNION ALL 会直接报错 Illegal mix of collations。这个点很多人调试半天才发现不是数据问题，而是元数据配置没对齐。
