sql语句的基本执行顺序是什么_mysql语法执行流程

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 写清楚。