MySQL中SELECT语句的实际执行顺序是FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY→LIMIT，而非书写顺序；WHERE不能引用SELECT定义的别名或聚合结果，HAVING才能过滤分组后数据，SELECT中计算和别名定义发生在过滤与分组之后。
SELECT 语句的实际执行顺序不是从 SELECT 开始的
MySQL（以及绝大多数 SQL 标准实现）在解析和执行 SELECT 语句时，**语法书写顺序 ≠ 执行顺序**。你写的 SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY 是人类可读的逻辑表达，但 MySQL 内部会按固定阶段依次处理。理解这个顺序，能帮你避开很多“为什么 WHERE 过滤不到聚合字段”“为什么不能在 WHERE 里用别名”这类问题。
MySQL 的真实执行流程是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT
这是关键路径，每一步输出都作为下一步的输入。注意几个关键点：
-
FROM和JOIN最先执行，确定数据源和连接结果集；如果有子查询或 CTE，也会在此阶段展开或物化 -
WHERE在GROUP BY之前，所以它只能过滤原始行，不能引用GROUP BY后产生的分组结果（比如COUNT(*)、AVG(price)） -
HAVING是唯一能过滤分组结果的子句，它作用于GROUP BY之后的临时分组表，因此可以写HAVING COUNT(*) > 1 -
SELECT实际上很晚才执行——列计算、别名定义（如price * 1.1 AS final_price）都在此时发生，所以WHERE和GROUP BY都看不到这个别名 -
ORDER BY在SELECT之后，因此它可以引用SELECT中定义的别名（MySQL 支持，但标准 SQL 不保证） -
LIMIT是最后一步，它截断最终排序后的结果，不影响前面任何计算逻辑
常见错误场景和对应原因
这些坑几乎都源于混淆了书写顺序和执行顺序：
- 写
WHERE avg_score > 80报错Unknown column 'avg_score'？因为avg_score是SELECT里算出来的，而WHERE此时还没到那一步 - 想按聚合结果排序却写了
ORDER BY COUNT(*)却报错？在没GROUP BY的语句里，COUNT(*)是标量聚合，但 MySQL 5.7+ 严格模式下会拒绝这种无分组的聚合列出现在ORDER BY（除非也在SELECT中出现） - 用
SELECT id, name, COUNT(*) FROM users不加GROUP BY，MySQL 可能返回任意一行的id和name，因为非聚合列未明确归属分组——这属于执行模型的隐式行为，不是 bug，但极易出错
一个直观验证执行顺序的示例
运行下面这条语句，观察结果和报错位置，就能印证流程：
SELECT id, COUNT(*) AS cnt FROM users WHERE status = 'active' GROUP BY id HAVING cnt > 5 ORDER BY cnt DESC;
如果把 HAVING cnt > 5 换成 WHERE cnt > 5，会立刻报错：Unknown column 'cnt' in 'where clause'——因为 WHERE 阶段 cnt 还不存在。
真正容易被忽略的是：SELECT 子句中的表达式（包括函数调用、别名、CASE WHEN）不仅影响输出，还可能触发隐式类型转换或 NULL 处理逻辑，而这些都发生在整个过滤和分组完成之后。这意味着性能敏感场景下，别把复杂计算塞进 SELECT 里再靠 WHERE 去“提前过滤”——该过滤的必须在 WHERE 写清楚。
