复杂SQL执行分逻辑顺序与物理计划两层：逻辑上按FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY→LIMIT处理；物理上依执行计划（如索引扫描、连接算法）真实调度。
复杂SQL的执行不是一蹴而就的线性过程，而是由数据库优化器按逻辑阶段逐层推导、转换和执行的。理解其拆解路径，关键在于抓住“逻辑执行顺序”与“物理执行计划”的差异——前者是SQL语义定义的先后关系（如WHERE先于GROUP BY），后者是数据库实际调度数据扫描、连接、排序等操作的底层策略。
一、逻辑执行顺序：SQL语句的语义层级
即使书写顺序是SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT，数据库仍按固定逻辑阶段处理：
- FROM + JOIN：确定数据源和连接方式，生成初始笛卡尔积（再通过ON过滤）
- WHERE：对上一步结果做行级过滤，减少后续计算量（尽早下推条件）
- GROUP BY：按列分组，触发聚合函数计算（COUNT、SUM等在此阶段求值）
- HAVING：对分组后的结果集过滤（只能引用GROUP BY列或聚合结果）
- SELECT：投影字段，可含表达式、别名、窗口函数（注意：此时不能引用WHERE中未出现的列）
- ORDER BY：对最终结果排序（若无索引支撑，可能触发文件排序FileSort）
- LIMIT / OFFSET：最后截取行数（但优化器可能提前应用以减少中间结果）
二、物理执行计划：数据库真实干活的步骤
用EXPLAIN（MySQL）或EXPLAIN ANALYZE（PostgreSQL）查看执行计划，关注以下核心节点：
- Table Scan / Index Scan：是否走索引？全表扫描代价高，应检查WHERE条件字段是否有合适索引
- Hash Join / Nested Loop / Merge Join：连接算法选择影响性能，小表驱动大表、等值连接倾向Hash Join
- Temporary Table + Filesort：出现即预警，说明GROUP BY或ORDER BY无法利用索引，需优化或加复合索引
- Using where; Using index：表示索引覆盖（Extra列中同时出现），无需回表，效率最高
三、典型复杂SQL拆解示例
以如下查询为例：
SELECT dept.name, COUNT(emp.id) AS cnt, AVG(emp.salary) FROM department dept LEFT JOIN employee emp ON dept.id = emp.dept_id WHERE dept.status = 'active' GROUP BY dept.id, dept.name HAVING COUNT(emp.id) > 5 ORDER BY cnt DESC LIMIT 10;
拆解执行流：
- 先加载department表，用status = 'active'快速过滤（若status有索引）
- 对每个存活部门，LEFT JOINemployee表；若emp.dept_id有索引，则走索引查找，否则全表匹配
- 按dept.id+name分组，统计人数、算平均薪资；COUNT和AVG在分组内实时计算
- 过滤掉员工数≤5的部门（HAVING作用于分组后结果）
- 对剩余部门按cnt倒序排，取前10；若无索引，会建临时表并排序
四、优化切入点：从执行计划反推问题
不看执行计划就调优，等于蒙眼修车。常见突破口：
- 发现type=ALL（全表扫描）→ 检查WHERE/JOIN条件字段是否缺失索引
- 看到rows值远大于实际返回行数 → 条件选择率差，考虑重写条件或更新统计信息
- 多个Using temporary → 尝试合并GROUP BY与ORDER BY字段，或用覆盖索引避免排序
- 子查询被标记为DEPENDENT SUBQUERY → 考虑改写为JOIN，避免对主表每行重复执行
