sql执行顺序是from→join→where→group by→having→select→distinct→order by→limit，而非书写顺序；from最先加载数据源并完成连接，是整个查询的逻辑起点。
FROM 阶段最先加载，不是 SELECT 开始执行
很多人写 SQL 时习惯从 SELECT 开始想逻辑，但数据库引擎真正在内存里干活时，第一步永远是 FROM。它不关心你要选什么字段，只管把表（或子查询、CTE）拉进来，生成初始数据集——哪怕你加了 WHERE id = 1，全表扫描也可能发生在这一阶段。
常见错误现象：WHERE 条件没走索引，却以为是写法问题；其实是因为 FROM 已经把大表全读进来了，WHERE 只是后续过滤。
- 多表
JOIN时，FROM和ON共同决定连接顺序和中间结果大小，优化器可能重排，但逻辑起点不变 - 如果
FROM包含子查询（如(SELECT ...)），该子查询会先完全执行并物化为临时“虚表”，再供后续步骤使用 -
WITH子句（CTE）默认是非物化的（PostgreSQL 12+ 可指定MATERIALIZED），但语义上仍属于FROM阶段的前置准备
WHERE 过滤不了聚合结果，HAVING 才能筛分组
WHERE 只作用于原始行，不能用 COUNT()、SUM() 等聚合函数，也不能引用 SELECT 中定义的别名——因为那些东西在 WHERE 执行时根本还没计算出来。
而 HAVING 是在 GROUP BY 分组完成后才运行的，所以它能访问聚合值和分组字段，但不能碰非分组列（除非是聚合函数包裹的）。
- 错误写法：
WHERE COUNT(*) > 10→ 直接报错，语法不合法 - 正确写法：
HAVING COUNT(*) > 10，前提是前面有GROUP BY - 性能影响：把本该在
WHERE做的行级过滤拖到HAVING，会导致更多行参与分组计算，显著拖慢查询
SELECT 别名在 ORDER BY 可用，但在 WHERE/GROUP BY 中不可见
SELECT 阶段才真正计算字段表达式、赋予别名，比如 SELECT price * qty AS total。这个 total 到 ORDER BY 才首次“出生”，所以 ORDER BY total 合法；但 WHERE total > 100 或 GROUP BY total 全部报错。
容易踩的坑：
- 误以为
ORDER BY 1（按第一列排序）总是安全——它依赖书写顺序，一旦SELECT改动列序，排序逻辑就悄悄变了 - 在
GROUP BY中写GROUP BY user_id, total→ 报错，必须写成GROUP BY user_id, price * qty或改用列位置（不推荐） - MySQL 允许
GROUP BY引用SELECT别名（兼容模式），但标准 SQL 和 PostgreSQL 严格禁止，跨库迁移时容易翻车
LIMIT 不影响逻辑结果集，只控制返回行数
LIMIT（或 TOP、FETCH FIRST）永远是最后一步，它不改变查询的语义结果，只是从最终排序后的完整结果集中截取前 N 行返回给客户端。
这意味着：
-
WHERE、GROUP BY、HAVING等所有前置步骤，都基于完整数据集运行，LIMIT对它们毫无影响 - 带
ORDER BY的LIMIT查询，数据库必须先完成全部排序才能截取——大数据量时很慢，可考虑加覆盖索引 - 分页场景用
LIMIT offset, size，offset 越大越慢，因为仍需跳过前 offset 行；游标分页（WHERE id > last_seen_id ORDER BY id LIMIT size）更高效
真实执行顺序里最易被忽略的一点：每个阶段输出一个虚拟表，仅作为下一阶段输入，且全程不可见。你写的 SQL 看似线性，实际是层层嵌套的管道，中间任何一步出错或低效，都会放大到后续所有环节。
