sql 中 select 语句真实执行顺序为：from → join → where → group by → 聚合计算 → having → select → distinct → order by → limit；该顺序决定了别名、聚合函数、过滤条件等的可见性与有效性。
SQL 中 SELECT 语句的执行顺序，并不等于你写 SQL 时从左到右的书写顺序。理解真实执行流程，能帮你写出更高效、逻辑更清晰的查询，也能快速定位 WHERE 过滤不到数据、GROUP BY 报错、ORDER BY 引用别名失败等问题。
FROM → JOIN：先确定数据来源
查询最先执行的是 FROM 子句，确定主表；如果有 JOIN，则紧接着完成表连接。此时生成的是笛卡尔积（未加 ON 条件）或连接后的中间结果集。数据库会基于统计信息和索引选择驱动表与连接算法（如 Nested Loop、Hash Join、Merge Join），这直接影响性能。
- 多表 JOIN 时，小表做驱动表通常更优
- ON 条件在 JOIN 过程中生效，用于筛选连接匹配的行
- LEFT JOIN 的右表若无匹配，对应字段补 NULL，但这一“补空”发生在 JOIN 阶段，后续 WHERE 对右表字段的非 NULL 限制可能把整行过滤掉（等价于 INNER JOIN）
WHERE：对连接结果做第一轮行级过滤
WHERE 在 FROM/JOIN 之后立即执行，作用于上一步产生的临时结果集，按条件逐行判断是否保留。它不能使用 SELECT 中定义的列别名，也不能使用聚合函数（如 SUM、COUNT），因为此时还未分组、也未计算聚合值。
- WHERE 中写 WHERE age > (SELECT AVG(age) FROM users) 会报错——子查询若为相关子查询则允许，但非相关子查询在逻辑上属于“编译期可求值”，多数引擎支持；真正不支持的是聚合函数本身
- 尽早用 WHERE 缩小结果集，能显著减少后续步骤的数据量
GROUP BY → 聚合计算 → HAVING
GROUP BY 将 WHERE 过滤后的结果按指定列分组，每组生成一行；接着执行 SELECT 中的聚合函数（COUNT、SUM、MAX 等）；HAVING 则对分组后的结果再次过滤，它能使用聚合函数和 GROUP BY 字段，但不能用未分组的普通列（除非是功能依赖列，部分数据库支持）。
- SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id HAVING c > 5 —— 正确，HAVING 引用了聚合别名
- SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING order_date > ‘2023-01-01’ —— 错误，order_date 未出现在 GROUP BY 中且非聚合字段
SELECT → DISTINCT → ORDER BY → LIMIT
SELECT 子句在此时才真正执行：计算表达式、取字段、应用列别名；DISTINCT 去重发生在这之后；ORDER BY 依据最终 SELECT 输出的列（包括别名）排序；LIMIT/TOP 则取排序后的前 N 行。注意：窗口函数（如 ROW_NUMBER()）也在 SELECT 阶段计算，但其执行依赖于 ORDER BY 和 PARTITION BY 的逻辑顺序。
- ORDER BY 可以写 SELECT 中定义的别名（如 ORDER BY total_price），因为此时 SELECT 已“逻辑完成”
- LIMIT 不改变结果逻辑顺序，只截断；若需稳定分页，必须配合 ORDER BY 使用确定性排序
- SELECT * 中的 * 在解析阶段就被展开为具体字段列表，不影响执行顺序
掌握这个顺序，你就知道为什么 SELECT 里写的别名在 WHERE 里用不了、HAVING 能用聚合而 WHERE 不能、以及为什么 LEFT JOIN + WHERE 右表条件会导致外连接失效。不复杂但容易忽略。
