MySQL中ORDER BY与UNION联用失效，求原因解析

核心原因拆解 #

1. UNION的执行逻辑限制单个SELECT的ORDER BY作用范围

MySQL中，UNION的执行优先级高于单个SELECT语句后的ORDER BY。如果直接在UNION的分支SELECT后写ORDER BY + LIMIT，这个ORDER BY并不是用来生成有序的结果子集，而是仅作为LIMIT的辅助——用来确定LIMIT要截取哪些行，但这个排序不会被保留；甚至如果没有LIMIT，该ORDER BY会被MySQL直接忽略。

你的失效代码中，看似是分别对两个表排序取前3条再合并，但实际MySQL不会按照这个逻辑执行：它可能跳过分支的排序步骤，直接随机取3条数据再合并，完全不符合你“先排序筛选再合并”的需求。

2. 派生表必须指定别名

当你把带ORDER BY + LIMIT的查询包装成子查询作为数据源时，这个子查询会被MySQL视为派生表。而MySQL的语法规则强制要求：所有派生表必须指定别名，否则会抛出Every derived table must have its own alias的错误。所以代码里的as a和as b是语法层面的硬性要求，不是可选操作。

代码对比解析 #

失效代码（不符合预期）

SELECT * FROM topstates ORDER BY TopState DESC LIMIT 3
UNION
SELECT * FROM bottomstates ORDER BY BottomState LIMIT 3;

此写法中，分支的ORDER BY仅为LIMIT服务，无法保证先排序再取数的逻辑，最终合并的结果可能完全不是你想要的前3条高/低数据。

生效代码（符合预期）

SELECT * FROM 
(SELECT * FROM topstates ORDER BY TopState DESC LIMIT 3) as a
UNION
SELECT * FROM 
(SELECT * FROM bottomstates ORDER BY BottomState LIMIT 3) as b;

这里每个子查询会独立执行：

• 先对topstates按TopState降序排序，截取前3条生成临时表a
• 再对bottomstates按BottomState排序，截取前3条生成临时表b
• 最后合并a和b的结果（UNION会自动去重并默认按第一列排序，若不需要去重可改用UNION ALL提升性能）

内容的提问来源于stack exchange，提问作者asdsashi