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右表条件会导致外连接失效。不复杂但容易忽略。
