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 的表（相关子查询）。这种作用域嵌套比表面看起来更严格。