MySQL 执行顺序这个问题几乎每天都有人在群里踩。写 SQL 写得顺手一跑报错要么是Unknown column要么是Invalid use of group function还有动不动就Using filesort、Using temporary。我在做性能调优和面试别人时发现十个人里至少有七个人说不清楚一条查询在 MySQL 内部到底按什么顺序执行。这真不是背几个关键字顺序那么简单它直接决定你的 SQL 能不能跑、跑得快不快、结果对不对。这篇内容就把执行顺序拆开聊透整理成可以直接抄的排查思路适合日常写 SQL 的开发、刚接手慢查询优化的运维以及准备面试的同行。如果你手里正好有 Navicat 或者命令行建议跟着每个例子实际跑一遍。执行顺序这种事儿光看没用得自己踩过坑才记得住。1. SQL 在 MySQL 里到底按什么顺序跑1.1 书写顺序和执行顺序是两套逻辑大家写 SQL 的习惯顺序一般是SELECT打头、FROM随后、接着WHERE、GROUP BY、HAVING、ORDER BY、LIMIT。但 SQL 标准定义的逻辑执行顺序完全不是这样MySQL 作为一个关系型数据库遵循的也是后一套。完整的逻辑顺序大致是这样的顺序逻辑步骤作用1FROM确定数据来源表逻辑上先把表加载进来2ON配合JOIN按关联条件拼接行3JOIN完成内连接或外连接形成中间结果4WHERE对中间结果逐行过滤保留满足条件的行5GROUP BY按指定列对行进行分组6HAVING对分组后的结果进行过滤7SELECT投影列计算表达式、别名8DISTINCT对结果去重9ORDER BY对最终结果排序10LIMIT / OFFSET截取指定行数这个顺序好比餐厅出菜客人看到的菜单是SELECT写在最前面但后厨真正干活时得先备料FROM、洗菜WHERE、切配GROUP BY、质检装盘SELECT、摆盘ORDER BY、限量上桌LIMIT。你只能在最终装盘的环节挑菜不能在洗菜的时候就把菜名报出来这就是很多报错的本质。有一点要单独说明DISTINCT在多数讲解中放在SELECT之后执行因为它是先投影再去看重复行。MySQL 的查询执行计划里没有和逻辑顺序严格一一对应的环节但理解这套顺序能解释绝大多数兼容性问题。1.2 优化器会改写执行顺序但逻辑结果不变数据库不是傻瓜式按步骤机械执行。MySQL 的优化器在拿到 SQL 后会先生成解析树再进行逻辑等价改写最后才生成执行计划。比如它可能把WHERE条件下推到子查询里执行可能调整多表连接的驱动顺序也可能把子查询改写成半连接。所以你在EXPLAIN里看到的实际执行顺序可能和上面那张逻辑顺序表不完全一致但最终结果必须保证等价。我经常举一个例子SELECT * FROM orders WHERE status 1这条语句逻辑顺序是先FROM orders再WHERE status 1。但如果status上有二级索引MySQL 实际执行时会先通过索引读取满足status 1的主键列再回表取完整行。这就相当于把WHERE的过滤提前到了FROM阶段完成物理执行和逻辑顺序是脱节的。理解这一点非常重要因为很多人在解释“执行顺序”时过于死板一旦发现实际执行和教科书不一致就懵了。我个人的实操建议是把逻辑执行顺序当成分析 SQL 正确性的“思维工具”把EXPLAIN输出当成判断真实性能的“事实依据”两者结合起来才不会被优化器的黑盒操作带偏。1.3 理解每一步做了什么才能预期结果每个逻辑步骤都不是摆设。FROM决定基础数据范围多表FROM时会先形成笛卡尔积也就是所有组合行JOIN的ON条件再逐步筛选。WHERE在聚合之前过滤行所以你不能在WHERE里使用COUNT()、SUM()这类聚合函数因为此时数据还没有分组聚合无从谈起。HAVING在分组之后过滤所以它可以使用聚合结果。SELECT这一步才计算别名和表达式因此它后面紧跟的ORDER BY可以引用别名而WHERE不行。最后LIMIT在ORDER BY之后执行所以排序完成后才取前 N 行。我见过一个典型错误有人统计每个分类的销售额想只保留销售额大于 100 的分类把SUM(amount)条件写在WHERE里报错之后又不知道该挪到哪个位置。根据执行顺序答案很明确WHERE先于GROUP BY无法看到聚合结果必须换成HAVING SUM(amount) 100。这就是我为什么坚持认为执行顺序不是八股文它是排查各种 SQL 报错的第一把钥匙。2. 执行顺序直接导致的三个高频翻车现场2.1 SELECT 别名在 WHERE 里失效在 ORDER BY 里却能生效这个坑几乎每个 MySQL 使用者都踩过。看这段 SQLSELECT order_id, SUM(amount) AS total_amount FROM orders WHERE total_amount 100 GROUP BY order_id;一执行MySQL 直接报错Unknown column total_amount in where clause。原因就是执行顺序里WHERE在SELECT之前别名在WHERE阶段根本不存在。想要过滤聚合结果正确写法是把条件挪到HAVING里SELECT order_id, SUM(amount) AS total_amount FROM orders GROUP BY order_id HAVING total_amount 100;但反过来同样的别名在ORDER BY里可以正常使用SELECT order_id, SUM(amount) AS total_amount FROM orders GROUP BY order_id ORDER BY total_amount DESC;因为ORDER BY靠后在SELECT已经完成投影之后执行引擎能识别出别名。这也是我在面试时最喜欢问的一句话“为什么 MySQL 允许ORDER BY用别名却不允许WHERE用”能答出“执行阶段先后不同”的人基本是真看过执行顺序的。另外注意如果你不是聚合场景而只是简单的列别名规则也一样WHERE里不能引用ORDER BY里可以。比如SELECT name AS n FROM users WHERE n 张三依然报错。想按别名过滤老老实实包一层子查询子查询的好处是它重新开启了一个“执行顺序阶段”外层WHERE就能看到内层SELECT产生的别名了。2.2 HAVING 和 WHERE 的边界问题本质是聚合前后很多人以为HAVING和WHERE只是语法差异、功能差不多这是一个非常大的误解。它们的边界就是执行顺序中GROUP BY的位置。WHERE在分组前执行处理的是原始行所以它的过滤条件不能包含聚合函数。HAVING在分组后执行处理的是“组”所以它能写COUNT(*) 1、SUM(amount) 100之类的条件但不能参与“组内每一行”的判断。举一个最常见的重复数据排查例子SELECT email, COUNT(*) AS cnt FROM users GROUP BY email HAVING COUNT(*) 1;这个HAVING COUNT(*) 1能正常工作因为它发生在分组之后。如果你把它换成WHERE COUNT(*) 1会得到Invalid use of group function错误这是因为执行到WHERE时根本还没有分组COUNT(*)无法计算。还有一个容易被忽略的点既然HAVING在最后做组级过滤那么在HAVING里使用WHERE已经过滤过的条件就是浪费执行资源。比如你已经用WHERE status 1过滤了状态就不需要在HAVING里再写一遍status 1因为按执行顺序那部分行早就不存在了。这虽然不会导致报错但会让执行计划多做一些无谓判断属于典型的“逻辑对但性能差”写法。2.3 ORDER BY、LIMIT 和 NULL 排序的隐藏坑LIMIT在ORDER BY之后执行这个执行顺序直接关系到分页查询的性能。你以为LIMIT 1000000, 20是“跳过 100 万行再取 20 行”实际上 MySQL 会先把整张表按ORDER BY排完序然后丢掉前 100 万条记录再返回后面的 20 条。排序本身已经花了很多时间和临时文件空间结果大部分又被丢弃这是很多深分页慢查询的根源。NULL 排序也和三年前很多人写错的细节有关。MySQL 里升序排序时 NULL 默认排在最前面降序排序时 NULL 默认排在最后面。如果你希望 NULL 固定出现在最前或最后就不能只写ORDER BY col ASC要这样处理SELECT * FROM users ORDER BY (age IS NULL) ASC, age ASC;这个写法把 NULL 判断转换成一个布尔值参与排序实质是改变了排序条件的逻辑顺序。还有组合排序比如ORDER BY score DESC, id ASC前面条件相同才轮到后面的条件这个我相信大部分人都懂但很少有人知道如果和GROUP BY混用MySQL 8.0 之前的版本会有隐式排序的坑GROUP BY在某些情况下默认按分组字段排序5.7 及以前版本还保留这种行为到了 8.0 直接取消了导致同一套 SQL 在升级后顺序变化。这其实是执行顺序没有完全覆盖的一个边界情况但排查时非常容易困惑。3. 多表 JOIN 和子查询的真实执行路径3.1 驱动表怎么选执行顺序不是由书写顺序决定多表查询里执行顺序最基础的体现就是“哪张表先被访问”。很多初学者误以为FROM后面写谁哪张表就是先访问的这是个经典误解。MySQL 的优化器会根据表大小、关联字段索引、过滤条件估算成本选择它认为最优的驱动表。在EXPLAIN输出结果里第一行就是驱动表它通常代表被先执行访问的表。默认策略是“小表驱动大表”也就是用小结果集去驱动大结果集的查询。它的执行方式类似于嵌套循环外层遍历驱动表每一行内层通过索引去被驱动表里查找匹配行。如果驱动表返回 100 行被驱动表关联字段有主键索引内层每次走索引查找整体开销可控反过来如果驱动表 1 万行内层表 5000 行且无索引那就是 1 万次全表扫描性能直接崩盘。在实战里调整 SQL 书写顺序不一定能改变驱动表因为优化器会自己重新排序但如果你的JOIN条件里能增加过滤性很强的WHERE条件优化器就可能据此选择更合适的驱动表。所以与其费劲调整FROM的顺序不如把单表过滤条件写好、把关联字段索引建好让优化器有更好的选择空间。3.2 子查询执行顺序IN 和 EXISTS 到底谁先跑子查询是另一个执行顺序容易让人混乱的场景。很多人背过口诀“EXISTS 比 IN 快”但这个结论在 MySQL 5.6 之后已经不再可靠。MySQL 5.6 以后引入了半连接优化IN (SELECT ...)这种形式可能会被改写成物化表或者半连接结构。优化器可能先把子查询结果物化成一张临时表再让外层表和临时表做关联也可能直接把它改写成类似 JOIN 的形式。也就是说你看到的IN子查询实际执行时可能是“先执行子查询、再执行外层查询”也可能被优化成“先扫描外层表、再逐个判断是否存在”。到底按哪种方式执行EXPLAIN结果会告诉你优化器会根据数据量动态决定并不是固定顺序。我自己实践下来有一个更实用的判断标准如果子查询结果集很小物化或者IN通常更快因为可以把子查询结果缓存下来重复使用如果子查询是关联子查询每行外层记录都要重新执行一次这时候用EXISTS配合被驱动表索引通常避免重复扫描整张临时表。不要死记执行顺序而是看这种查询涉及哪一步先执行、哪一步被反复触发这才是执行顺序思维在生产场景的正确用法。3.3 用 EXPLAIN 看真实执行顺序而不是靠猜想验证真实执行顺序唯一可靠的方法是看执行计划。拿一个真实例子来说假设有订单表orders和用户表users查询近 30 天下单用户的信息SELECT u.id, u.name, o.order_id FROM users u INNER JOIN orders o ON u.id o.user_id WHERE o.created_at 2024-11-01 AND o.created_at 2024-12-01;执行EXPLAIN后你会看到id、select_type、table、type、key、rows、Extra这些列。其中table列就是实际访问表的顺序type显示访问类型比如const、ref、range、ALLkey显示哪个索引被选中rows是优化器估算的扫描行数Extra里常见的Using index condition表示索引条件下推Using filesort表示排序在文件或内存中进行Using temporary表示使用了临时表。看执行计划时要重点关注rows和key如果关联查询第二行是ALL且rows很大说明被驱动表没有用到索引执行顺序里每次循环都要全表扫这比任何逻辑顺序都更影响实际性能。我把EXPLAIN当作执行顺序的“告警器”Extra里一旦出现Using filesort或Using temporary且数据量大基本就意味着执行顺序导致排序或去重无法走索引需要针对GROUP BY或ORDER BY字段调整索引。4. 把执行顺序变成调优和面试的实战工具4.1 通过改写 SQL 让过滤提前缩小每一步的数据量执行顺序不是背完就完它能指导我们主动改写 SQL。其核心思路只有一句“能提前过滤就不要等到最后才过滤。”看一个实际改写的案例。原始写法SELECT o.order_id, u.name FROM orders o INNER JOIN users u ON o.user_id u.id WHERE o.user_id IN ( SELECT id FROM users WHERE status 1 );这条查询先关联orders和users再从用户表里筛status 1逻辑上没错但orders表很大时关联开销很大。更好的写法是把过滤条件合并到 JOIN 关联前或者直接先把符合条件的用户缩小成结果集再关联SELECT o.order_id, u.name FROM orders o INNER JOIN ( SELECT id, name FROM users WHERE status 1 ) u ON o.user_id u.id;这个改写利用的执行顺序原理是派生表u会先于外层JOIN执行先把用户数量缩小再参与关联后面整个执行路径上的数据量都小一圈。在 MySQL 5.7 及以上版本派生表还有可能被合并或物化配合合理索引性能提升非常明显。类似的思路还包括把WHERE条件尽量写到最内层子查询里、用EXISTS代替关联子查询、在GROUP BY之前先用WHERE把无关数据过滤掉等等。这些都体现了执行顺序的思想前面的步骤越小后面步骤的压力越低。4.2 根据执行顺序设计联合索引让排序和分组不再走临时表索引设计和执行顺序关系非常紧密。逻辑顺序中WHERE先执行所以联合索引的最左前缀优先考虑WHERE等值条件字段比如WHERE status 1 AND created_at ...在(status, created_at)上建联合索引就能高效过滤。再往下走GROUP BY和ORDER BY在SELECT前执行所以如果一条 SQL 既要过滤又要分组排序索引设计的一般策略是先放WHERE的等值条件列再放GROUP BY或ORDER BY的列这样索引顺序与执行顺序匹配MySQL 就能通过索引有序性完成排序避免Using filesort。举个例子下面这条查询SELECT category_id, COUNT(*) FROM goods WHERE status 1 GROUP BY category_id ORDER BY category_id;最理想的联合索引是(status, category_id)先过滤再分组排序索引天然有序执行计划里不会出现Using filesort。如果你把索引建成(category_id, status)过滤效果和排序效果都会打折执行时可能先分组排序再逐行回表过滤status中间临时表和回表开销都来了。这就是执行顺序对物理设计的牵引作用也是我评估一个索引是否合理时最先观察的 SQL 结构。4.3 面试高频题和线上排查速查清单我把执行顺序相关的面试题和线上排查要点整理成一张表方便你在面试前或者处理慢查询时直接对照。问题答案要点为什么WHERE里不能使用SELECT别名WHERE执行顺序在SELECT之前别名此时尚未生成HAVING和WHERE谁先执行WHERE先执行过滤原始行HAVING后执行过滤分组ORDER BY里能用别名吗可以ORDER BY在SELECT之后执行LIMIT在排序前还是排序后排序之后所以大偏移量分页会产生较大排序开销JOIN的驱动表由谁决定优化器根据成本和行数估算决定FROM书写顺序不是绝对依据IN和EXISTS谁快老说法不可靠5.6 之后有半连接优化用EXPLAIN判断GROUP BY会隐式排序吗MySQL 5.7 及以前部分场景会8.0 已取消NULL在排序中的默认位置升序在最前降序在最后可通过布尔表达式调整线上排查慢查询时我建议按这个顺序做先看 SQL 是否符合逻辑执行顺序查找有没有WHERE使用别名、HAVING使用无效条件这类逻辑错误然后跑EXPLAIN看驱动表、索引使用、rows估算和Extra里的排序/临时表最后判断是否可以通过改写子查询、提前过滤、增加合理联合索引来让执行路径符合预期。这套方法我用了很多年基本能覆盖绝大多数执行顺序引发的正确性和性能问题。最后分享一个我在实际项目中踩过的坑曾经有一条统计报表 SQL 在小数据量测试环境跑得飞快一到生产就几十秒超时。排查到最后问题出在GROUP BY字段和ORDER BY字段顺序不一致导致数据量上来后Using filesort直接把内存排序拖垮。后来按照执行顺序调整了联合索引把排序字段纳入索引后缀查询耗时从 30 多秒降到了 1 秒以内。从那以后我每次写复杂 SQL 都会先在草稿纸上默写一遍逻辑执行顺序再想索引和改写策略。执行顺序这门基本功看着简单真到现场救命的时候比什么玄乎调优技巧都管用。