SQL执行顺序严格为FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY：FROM先确定数据源，WHERE才能基于其列筛选；WHERE不可用SELECT别名或未声明表；错误在解析阶段即报“列/表不存在”。

FROM 为什么必须在 WHERE 前面？

因为 SQL 是声明式语言，但执行顺序是严格分阶段的：FROM 阶段决定了“数据从哪来、有哪些列、哪些行初步可见”，WHERE 阶段才基于这个结果集做筛选。没有 FROM，WHERE 就像问“把谁的年龄大于 30？”——连“谁”都还没定义。

WHERE 能否引用还没出现的表或别名？

不能。数据库解析器按语法顺序检查依赖关系，WHERE 中出现的列名必须已在 FROM（含 JOIN）中明确引入。常见错误包括：

• SELECT name FROM users WHERE dept_id IN (SELECT id FROM depts) —— 这合法，因为子查询独立解析
• SELECT u.name FROM users u WHERE u.dept_id = d.id —— 错误！d 在 FROM 中未声明，报错 Unknown column 'd.id'
• SELECT name AS n FROM users WHERE n = 'Alice' —— 错误！AS n 是 SELECT 阶段才生效的别名，WHERE 看不到它

那 ORDER BY 和 GROUP BY 的位置逻辑一样吗？

不完全一样，但都受执行阶段约束：

• GROUP BY 在 WHERE 之后、HAVING 之前，所以它只能引用 FROM 提供的原始列或聚合表达式，不能用 SELECT 中的别名（除非数据库支持，如 PostgreSQL 允许，但 MySQL 不允许）
• ORDER BY 是最后执行的阶段之一，因此它可以引用 SELECT 列名或别名（ORDER BY n 合法），甚至位置序号（ORDER BY 1），但这属于语法糖，不是逻辑上的“提前可见”
• 所有这些阶段的顺序本质是：先有数据源（FROM），再过滤行（WHERE），再分组（GROUP BY），再筛组（HAVING），再计算输出列（SELECT），最后排序（ORDER BY）

写错顺序时，数据库到底报什么错？

不同数据库提示略有差异，但核心指向“标识符未定义”或“表/列不存在”：

• MySQL：直接报 Unknown table 'xxx' 或 Unknown column 'yyy'
• PostgreSQL：更明确，如 column "z" does not exist，并指出发生在 WHERE 子句
• SQL Server：Invalid column name 'a'，且错误位置标记在 WHERE 行
• 注意：这些不是运行时报错，而是解析/编译阶段就失败——说明 SQL 引擎根本没走到执行，只是语法树构建不过关

真正容易被忽略的是子查询嵌套层级里的 FROM 作用域：外层 WHERE 看不到内层 SELECT 的别名，但内层 WHERE 可以用外层 FROM 的表（相关子查询）。这种作用域嵌套比表面看起来更严格。