UNION 去重且可能隐式排序，UNION ALL 不去重、不排序、性能更高；字段数须一致，类型宜兼容，列名以首个 SELECT 为准，排序须置于末尾；无重复时优先用 UNION ALL。
UNION 和 UNION ALL 在 phpMyAdmin 里执行结果不一样？
是的，差别就在去重和性能上。union 会自动去重并隐式排序（mysql 8.0.31+ 后默认不排序，但依然去重），union all 完全不做处理，原样拼接。你在 phpmyadmin 的「sql」标签页里写查询，看到的结果集行数不同，大概率就是这个原因。
- 如果两个子查询有重复行，
UNION返回更少行；UNION ALL行数 = 子查询行数之和 - phpMyAdmin 不会对结果再做去重或排序——它只是展示 MySQL 返回的结果，所以差异完全由 SQL 本身决定
- 没有
ORDER BY时，UNION ALL的顺序是不确定的（取决于执行计划），别依赖它“看起来有序”
在 phpMyAdmin 中写 UNION 查询要注意哪些语法坑？
phpMyAdmin 对 SQL 解析很直接，不加修饰，所以常见报错基本都是语法或结构问题。
- 每个
SELECT的字段数量必须一致，否则报错：ERROR 1222: The used SELECT statements have a different number of columns - 对应列的数据类型最好兼容（比如不能一个是
VARCHAR，另一个是INT），否则 MySQL 可能静默转类型，导致值被截断或变成 0 - 列名以第一个
SELECT为准，后面子句的别名不会生效；想统一列名，得在第一个SELECT里用AS - 不能对单个子句加
ORDER BY，除非配合LIMIT；整个联合结果排序，只能在最后加一个ORDER BY
什么时候该用 UNION ALL 而不是 UNION？
绝大多数你能确定没重复、或者根本不在乎重复的场景，都该用 UNION ALL——它更快，资源消耗更低。
- 合并日志表、分表数据（如
orders_2023和orders_2024）：天然无重，用UNION ALL - 查多个独立状态的数据（如
status = 'pending'和status = 'processing'）：WHERE 条件互斥，无重 - 在 phpMyAdmin 里跑分析类查询，响应慢？先检查是不是误用了
UNION——去掉ALL可能让查询从 3 秒变 0.2 秒 -
UNION内部要建临时表 + 排序 + 去重，而UNION ALL就是追加，几乎没有额外开销
phpMyAdmin 界面里怎么验证 UNION 是否生效？
别只看结果行数，重点看「影响的行数」提示和实际内容是否符合预期。
- 执行后，phpMyAdmin 底部会显示类似
25 rows affected（其实是“返回”，不是“影响”），这个数字就是最终结果集行数，对比你两个子查询单独执行的行数和 - 手动加
SELECT COUNT(*)包一层，比如：SELECT COUNT(*) FROM (SELECT id FROM t1 UNION SELECT id FROM t2) AS u;
- 想确认有没有真去重？挑几个疑似重复的值，分别查它们在各子表中的出现次数：
SELECT COUNT(*) FROM t1 WHERE id = 123;和SELECT COUNT(*) FROM t2 WHERE id = 123;
UNION 的去重逻辑是整行比对，哪怕只有一列不同，也算不同行——这点容易被忽略，尤其当字段里有 NULL 或空字符串时。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
