MySQL执行顺序为FROM→JOIN→ON→WHERE→GROUP BY→HAVING→SELECT→ORDER BY→LIMIT；每步生成虚拟表，决定WHERE与ON差异、HAVING可用别名、ORDER BY能引用SELECT别名等语义约束。
FROM → JOIN → ON → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT，顺序不能错
MySQL 执行一条 SQL 语句时，并不是按你写的顺序从上到下执行的。它有一套严格的逻辑执行顺序，每一步都生成一个虚拟表（VT），作为下一步的输入。这个顺序直接决定 WHERE 和 ON 的行为差异、HAVING 能否用别名、ORDER BY 为什么能引用 SELECT 中的别名——这些都不是“语法糖”，而是执行流程决定的。
ON 和 WHERE 都是过滤，但时机不同，LEFT JOIN 下结果可能天差地别
在 LEFT JOIN 场景中，ON 是在连接阶段（VT2）就筛选，而 WHERE 是在连接完成、外部行已补全之后（VT4）才过滤。一旦你在 WHERE 里写了左表字段条件，就可能把 LEFT JOIN 补上的 NULL 行又干掉了，让外连接退化成内连接。
-
LEFT JOIN score ON student.name = score.name WHERE student.class = 'A'：先连再筛，class = 'A'会剔除所有非 A 班学生（包括没成绩的），结果只剩 A 班有成绩记录的学生 -
LEFT JOIN score ON student.name = score.name AND student.class = 'A'：把班级条件放在ON里，才能确保 A 班所有学生（含缺考）都在最终结果中
GROUP BY 后才能用聚合函数，HAVING 必须跟在 GROUP BY 后面
SELECT 看似写在最前面，实际执行很晚；而 GROUP BY 是第 5 步，这时原始行才被分组压缩成组记录。所以：AVG()、COUNT() 这类聚合函数只能在 GROUP BY 之后合法使用；HAVING 是唯一能在分组后对组做条件过滤的子句，它不能用非分组字段（除非是聚合结果），也不能替代 WHERE 做行级过滤。
- 错误写法：
SELECT name, COUNT(*) FROM user WHERE COUNT(*) > 1 GROUP BY dept——COUNT(*)在WHERE阶段还不存在 - 正确写法：
SELECT dept, COUNT(*) c FROM user GROUP BY dept HAVING c > 1—— 分组后，c是 VT5 中的列，HAVING可以引用
SELECT 是第 8 步，DISTINCT、ORDER BY、LIMIT 全都依赖它产出的列
这意味着你在 ORDER BY 或 LIMIT 里能用的字段，必须出现在 SELECT 列表中（或由其衍生），否则报错；DISTINCT 去重的对象也是 SELECT 输出的整行，不是原始表的行。另外，SELECT 中定义的别名，在 ORDER BY 和 LIMIT 中可用，但在 WHERE 或 GROUP BY 中不可用——因为它们执行得更早。
- 允许：
SELECT name AS n FROM user ORDER BY n - 报错：
SELECT name AS n FROM user WHERE n = 'Tom'（提示 Unknown column 'n'） - 注意：
SELECT id FROM user LIMIT 10 OFFSET 20的OFFSET是在排序后才跳过的，没ORDER BY时结果不稳定
真正容易被忽略的，是执行顺序和语义绑定的强约束：不是“能不能写”，而是“这个位置根本还没算出来”。写 SQL 时盯着虚拟表流转，比死记口诀管用得多。
