最近在排查一个生产环境慢查询时我发现了一个特别典型的现象一条三表联查 SQL数据量总共不过一百多万行其中一个核心表的过滤字段明明有索引执行计划却走了全表扫描。我盯着 EXPLAIN 看了好一会儿最后在 WHERE 条件里发现了罪魁祸首——一个将时间字段格式化成字符串再参与比较的 DATE_FORMAT 函数。函数本身完全没问题问题在于它出现的位置触发了执行顺序中最容易被忽略的一条规则WHERE 阶段是在条件匹配阶段逐行计算表达式的而这一步会直接切断 B 树索引的快速定位能力。这个案例恰好就是我想聊的主题MySQL 查询语句的执行顺序以及在查询过程中函数到底是怎么被调用的。理解这两个点不只是为了应付面试更是真实环境里优化慢查询、看懂执行计划、避免“看起来能走索引实际却走不了”的必备基本功。很多时候你觉得自己写的 SQL 和慢查询没关系但只要你理解执行顺序再回头看那些看似玄学的性能问题基本都能找到逻辑上的漏洞。1. 为什么执行顺序是 SQL 优化的第一课1.1 书写顺序与逻辑执行顺序的区别很多人在刚学 SQL 时就记住了标准写法SELECT 在最前面然后是 FROM、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT。这种书写顺序给人的错觉是数据库会从上到下读取语句先算 SELECT再算 FROM。这是最常见的误解之一。MySQL 的逻辑执行顺序并不是根据写 SQL 的顺序来的而是先确定数据来源再做行级过滤再做分组和聚合最后才做列的投影和排序。完整的逻辑顺序可以整理成下面这张表逻辑阶段核心动作常见误区FROM确定数据来源执行 JOIN生成虚拟结果集认为先执行 SELECT忽略了 JOIN 会产生笛卡尔积WHERE逐行过滤虚拟结果集不能使用聚合函数和别名误把聚合条件放在 WHERE 中导致语法报错GROUP BY按指定列分组为聚合函数计算做准备认为分组前就可以看到聚合结果HAVING对分组后的结果过滤可以使用聚合函数和 WHERE 混淆导致过滤时机错误SELECT计算列、表达式、函数生成最终结果列认为 SELECT 最先执行试图在 WHERE 里引用别名DISTINCT对结果去重忽略去重时机导致排序时数据集异常ORDER BY对最终结果排序没意识到排序发生在所有过滤和投影之后LIMIT限制返回行数以为 LIMIT 能减少之前的排序和扫描成本这个序列在教材里写过无数遍但真正会用它来思考问题的人并不多。比如一个经典报错在 WHERE 条件里引用了 SELECT 子句中定义的别名MySQL 直接报“Unknown column”很多新手第一反应是“列明明写了啊”。理解了执行顺序你就会明白WHERE 在 SELECT 投影之前执行别名在那个阶段根本不存在。反过来如果你在 HAVING 或 ORDER BY 里使用别名情况又不一样因为 HAVING 在 SELECT 之后才执行ORDER BY 更是靠后的阶段。1.2 每一步到底做了什么为了把抽象的顺序落到具体的操作上可以把这八个阶段想象成一条流水线。假设有订单表 orders、用户表 users 和订单明细表 order_items现在想统计每个用户的订单总金额只保留金额超过 1000 的统计结果最后按金额倒序展示前十条。这条 SQL 会先经过 FROM 把三张表关联起来生成一个包含用户信息和订单明细的中间数据集然后 WHERE 把无效订单、退货单或某些状态不对的行过滤掉接着 GROUP BY 按 user_id 分组HAVING 对分组后的总金额做二次过滤SELECT 阶段才算出来 SUM(order_items.amount) 这个表达式ORDER BY 再对 sum_amount 排序最后 LIMIT 10。从执行计划的角度看优化器并不一定严格按这个顺序重排但逻辑语义必须符合这条顺序。WHERE 中的条件越早过滤掉越多行后续参与分组和排序的数据量就越小这就是为什么我们要把选择性高的过滤条件放在 WHERE 中而不是全部丢给 HAVING。很多时候两条 SQL 写法不一样优化器最终生成的结果一致但因为书写方式影响了解析和优化成本导致执行计划完全不同。另外需要注意的是逻辑执行顺序中也存在部分重排的情况。MySQL 的优化器会把能合并的谓词下推会把子查询改写为半连接会在驱动表选择上做代价估算。所以不能仅凭逻辑顺序就对执行计划进行脑内推断而是要用 EXPLAIN 去验证。但逻辑顺序的价值在于帮你建立业务语义层面的直觉一个列别名能不能用一个聚合函数应该放在哪里一个函数调用到底会导致多少次计算都能从这个顺序里推出来。2. 执行顺序如何影响索引与连接策略2.1 WHERE 阶段慢查询的真实案例回到开头提到的那个慢查询案例。表结构大概是这样的一张订单流水表里面有一个 create_time 字段类型是 datetime上面建了索引。业务需求是查某一天的所有订单常规写法是 WHERE create_time 2024-01-01 00:00:00 AND create_time 2024-01-02 00:00:00。但同事写成了 WHERE DATE(create_time) 2024-01-01。从逻辑执行顺序来看WHERE 阶段要对每一行调用 DATE() 函数把 datetime 值转换为日期格式然后与常量比较。问题在于 DATE(create_time) 是一个以列作为参数的表达式MySQL 优化器很难把它直接反向推导成 create_time 的范围条件所以即便 create_time 上有索引也无法用来快速定位。整个查询就退化成全表扫描每条记录都要算一次函数性能自然直线下降。排查后把 SQL 改成范围写法执行计划从全表扫描 typeALL 变成了索引范围扫描 typerange查询耗时从 900 多毫秒降到了 30 毫秒以内。这里的关键不是 DATE() 函数本身慢而是函数参与表达式计算后切断了索引列与查询条件之间的等值或范围映射关系。理解这一点后当你看到 WHERE 条件里出现对索引列的函数包裹几乎可以直接判断这是一个潜在的性能雷。还有一个容易被忽略的问题是谓词顺序。在逻辑上WHERE 中的条件会尽可能早地使用但 MySQL 并不会严格按照书写顺序一个个判断优化器会按成本做条件重排。不过这并不意味着你可以随意乱写 WHERE 顺序毕竟优化器的能力有限复杂的函数表达式可能会阻碍它进行有效的条件排序导致过滤效果变差。2.2 ORDER BY 与 GROUP BY 的排序陷阱执行顺序对排序和分组的影响也很值得展开说。很多人以为 ORDER BY 只是最后排个序没什么技术含量。但如果 ORDER BY 的列上有索引MySQL 可以直接利用索引的有序性省掉 filesort而如果 ORDER BY 后面接了一个函数或表达式比如 ORDER BY RAND() 或 ORDER BY CONCAT(name, age)那么优化器通常只能生成结果集然后对所有数据做一次外部排序。GROUP BY 也一样。如果 GROUP BY 的列上有索引MySQL 可以按索引有序扫描边扫描边分组如果没有分组列索引或者 GROUP BY 中包含函数表达式就可能出现临时表和 filesort。这在执行计划里非常直观Extra 列如果出现了 Using filesort 或 Using temporary就说明在某个阶段存在额外的排序或临时表操作。另一个容易被忽略的问题是 ORDER BY 与 LIMIT 的组合。当 SQL 里同时出现 ORDER BY 和 LIMIT 时逻辑顺序是先排序再截断所以排序成本不会因为 LIMIT 而降低除非优化器能利用索引的有序性否则 MySQL 还是要先完成完整排序。这一点在高分页场景下特别明显OFFSET 很大时前边的排序和扫描成本全都要付出这也是为什么很多人会把深度分页优化为“返回上一页最大 id再做范围过滤”。2.3 JOIN 驱动顺序带来的“先过滤后关联”执行顺序里 FROM 阶段比 WHERE 早但在 JOIN 时优化器选驱动表和被驱动表的顺序会对性能产生巨大影响。逻辑上 JOIN 产生的是笛卡尔积后再过滤但实际 MySQL 在做嵌套循环连接时会优先选择结果集更小的表作为驱动表并且在驱动表扫描过程中就把适合下推的 WHERE 条件应用上。这就是为什么同一个 SQL只要 A 表和 B 表的角色互调执行计划就完全不同。从执行顺序的角度去理解 JOIN 的优化需要知道“过滤条件下推”这个概念。比如 WHERE 条件里同时涉及 A.id B.a_id 和 A.status 1如果 A 作为驱动表优化器会在扫描 A 时先用 status 1 过滤再拿结果去 B 表逐行匹配这样 B 表被访问的次数会少很多。相反如果条件写在 ON 里或者优化器选了错误的驱动表就可能导致被驱动表被反复扫描产生额外的扫描成本。这个过程里函数同样会捣乱如果 A.status 上用了函数驱动表的过滤无法走索引可能连优化器的统计信息都受影响后续 JOIN 顺序的选择也会出现偏差。3. MySQL 函数调用机制不止是写个函数那么简单3.1 函数在解析器、优化器、执行器中的流转函数调用机制的深入理解不能停留在“函数可以用在 SQL 里”这个层面。一条 SQL 从客户端发出到返回结果会经过连接器、解析器、优化器、执行器几个模块。解析器会先识别出 SQL 中的函数名校验函数是否存在、参数个数是否正确并把函数调用以节点形式挂到语法树上。优化器阶段函数是否可被下推、是否会被多次计算会直接参与优化决策。执行器阶段函数才真正被逐行调用。一个常见的疑问是“SELECT NOW() 中的函数会被调用几次”理论上如果 NOW() 在 SELECT 列表里对多行结果调用MySQL 会保证它在同一条 SQL 执行期间返回一致的结果因为 NOW() 是语句级时间函数。但如果是 RAND()那每一行都可能得到不同的随机值如果是用户自定义函数或存储函数要看你有没有在函数内部访问表数据或者使用随机数、系统时间等变量。MySQL 对函数大致分为确定性的和非确定性的非确定性函数会让优化器更谨慎甚至在复制场景下产生主从不一致风险。函数调用发生的阶段与执行顺序是绑定的。你在 WHERE 中写了一个自定义函数执行器就会对每一行调用一次你在 SELECT 列表中写的函数则是对每一条投影后的行调用。若函数出现在 HAVING 中调用次数则等于分组数量。这种调用时机的差异直接决定了函数对性能的影响范围。比如 WHERE 条件里有一个耗时的自定义函数数据量一上来函数调用的累计消耗会非常惊人但如果把它挪到最后的 SELECT 投影中影响范围就只集中在最终返回的那些行上。3.2 存储函数、DETERMINISTIC 与复制安全MySQL 里可以创建存储函数也就是用户定义的 SQL 函数。创建时需要指定 DETERMINISTIC 等属性。很多人创建存储函数时不写 DETERMINISTIC或者写 NO SQL、READS SQL DATA以为无所谓。实际上这会带来两个问题。第一个问题是优化限制。如果一个函数是非确定性的比如内部用了 RAND()、UUID() 或者 GET_LOCK()那么优化器无法判断它在两次执行之间是否会改变结果因此某些优化措施会被禁用。查询中如果非确定性函数出现在 WHERE 条件中对索引列进行计算那么这条查询基本没有机会使用索引。第二个问题是复制安全。在主从架构下如果存储函数修改了数据又没有正确声明 DETERMINISTIC那么从库在重放 binlog 时可能产生不一致的结果。MySQL 官方文档要求用户对自定义函数做出准确声明否则复制的可靠性就没有保障。我见过一个比较典型的例子有人写了一个获取当前月份的函数内部用了 CURDATE()然后在查询条件里用这个函数去比较订单月份。因为非确定性函数的参与这个查询无法被优化器长期缓存执行计划每次执行计划都要重新生成同时 WHERE 条件对索引列的函数包裹又造成索引失效。最终解决方案很简单把函数调用挪到应用层先算出具体的月份值再作为常量传入 SQL。这样既保留了业务逻辑的清晰度也避开了函数对优化器的影响。3.3 函数副作用与索引失效的隐雷除开性能函数副作用也值得单独说。所谓副作用就是函数除了返回值之外还修改了外部状态比如修改会话变量、临时表或者调用了 RAND() 导致结果不稳定。这类函数一旦写入 WHERE 条件就可能出现同一条 SQL 两次执行返回不同行数或者执行计划不稳定的情况。最常见的隐雷是隐式类型转换。当函数不是显式出现而是由 MySQL 自动触发时很多人根本发现不了。例如一个 varchar 类型的手机号字段如果你拿它和数字类型比较MySQL 会自动调用 CAST 把 varchar 转成数字相当于对索引列应用了隐式函数。我排查过一个诡异问题手机号注册数量统计时某几条记录被漏掉排查到最后一查执行计划发现查询里用了 phone 13800000000 的写法MySQL 把字符串列转成数值比较遇到非纯数字的号码就出现了不匹配。这一类隐式转换在 EXPLAIN 中不会显示你写的函数但 type 列往往直接从 range 掉到 ALL基本就能判断出来。还有一类容易踩的坑是在 ORDER BY 中使用函数。比如你要对备注字段去除前后空格后排序写成 ORDER BY TRIM(remark)这个操作本身没问题但会让有序索引完全失效。更好的做法是在应用层预处理字段或者使用 MySQL 5.7 之后支持的生成列把 TRIM(remark) 的结果固化到一个虚拟列中并在该虚拟列上建索引。这样既能保留业务语义的清晰性又能继续享受索引带来的有序扫描优势。4. 实战排查当执行顺序与函数机制碰撞在一起4.1 常见报错速查与根因分析说到执行顺序与函数机制碰撞最直接的反馈就是一串串报错。我把实际工作中高频出现的几类问题整理成一个速查表报错信息根因分析解决建议Unknown column alias in where clauseWHERE 阶段无法识别 SELECT 别名改用原始列名或在外层查询再过滤Invalid use of group function聚合函数出现在 WHERE 中而 WHERE 不执行聚合逻辑将聚合条件移到 HAVING或改写为子查询Illegal mix of collations函数返回的字符集与表列字符集不一致显式指定 COLLATE或统一字符集和排序规则This function has none of DETERMINISTIC...创建存储函数时缺少必要属性声明根据实际语义补充 DETERMINISTIC / NO SQL 等Table xxx is specified twice子查询和外层查询引用了同名表导致关联歧义给表起别名明确引用关系这里要特别强调“聚合函数出现在 WHERE 中”这个错误。逻辑执行顺序里WHERE 是在 GROUP BY 之前执行的它只能处理原始行根本看不见聚合结果。所以 where count(*) 1 必然报错。如果你真的需要过滤分组之后的结果要么用 HAVING要么把聚合结果放到子查询里再在外层用 WHERE 过滤。理解了顺序这类报错基本不需要查文档。还有一个容易被忽略的报错是函数参数类型不匹配。比如某个函数传入了 NULL 值导致整个表达式返回 NULL进而影响筛选结果。在 MySQL 中很多函数遇到 NULL 会返回 NULL而不是报错或返回空字符串这会让业务逻辑变得很隐蔽。排查时要特别注意 WHERE 条件里函数对 NULL 的处理方式否则很容易出现“为什么这条记录没查出来”的疑惑。4.2 通过执行计划定位函数导致的性能瓶颈排查函数调用导致的性能问题EXPLAIN 是最好的切入点。在 MySQL 8.0 里我一般先执行 EXPLAIN ANALYZE它会输出每一步实际执行的时间、行数和循环次数。这一步对定位“函数是不是在循环里被反复调用”特别有帮助。举个例子执行计划中如果出现 Using where说明有额外的条件过滤而这个过滤很可能就发生在无法用索引快速定位的情况下。此时再观察 rows 列如果 rows 预估很大但最终输出结果很少往往就是函数或表达式让优化器没法利用统计信息。进一步用 EXPLAIN ANALYZE 看 actual rows 和 actual time你会发现每一行都要调用一次表达式计算循环次数巨大而这正是函数调用机制与执行顺序结合的现场。还有一个技巧用 optimizer trace 看优化器最终选择了哪条路径。在 MySQL 中设置 optimizer_traceenabledon再执行查询然后查询 INFORMATION_SCHEMA.OPTIMIZER_TRACE就能看到优化器是否尝试过索引合并、是否把条件下推、是否将子查询转换为半连接。遇到奇怪的性能问题时它比 EXPLAIN 更能还原决策过程。不过 optimizer trace 输出很冗长需要抓关键字段比如 considered_execution_plans 里的 cost 变化以及 condition_processing 里的 predicate 下推情况。4.3 生产环境优化建议清单结合执行顺序和函数调用机制我在生产环境里的优化建议可以归纳成一条可操作的清单优先保证 WHERE 条件中的索引列保持“裸列”任何对列的函数包裹都会增加优化器推导范围条件的难度。如果业务必须按日期过滤写成范围条件必须按年、月过滤考虑生成列。SELECT、ORDER BY、GROUP BY 中的函数尽量在应用层完成。让数据库只承担存储和必要的数据处理把字符串格式化、日期计算放到后端服务里既能降低数据库 CPU也让 SQL 更容易走索引。使用存储函数时准确声明 DETERMINISTIC、NO SQL 或 READS SQL DATA。声明后优化器才有可能对函数结果做常量折叠或缓存也能降低复制风险。对高频使用的函数表达式比如 DATE(order_time)、YEAR(create_time)可以建立生成列并加索引。MySQL 5.7 引入了生成列8.0 支持索引虚拟列可以让“看起来无法用索引的查询”重新走上索引路径。在深度分页场景里用“上一页最大 ID”替换 OFFSET LIMIT避免 LIMIT 阶段之前必须完成全量排序的问题。每次新 SQL 上线前至少跑一次 EXPLAIN重点看 type 是否达到了 range 或 refExtra 里是否出现了 Using filesort 或 Using temporary。5. 一些当排坑后的个人体会聊了这么多其实我想表达的核心就一句话MySQL 的执行顺序和函数调用机制不是互相独立的概念。函数调用到底发生在哪个执行阶段决定了它对索引和性能的影响方式而执行顺序又决定了函数能不能被识别、能不能被下推、能不能被缓存。多想想这两个问题很多“玄学”慢查询和诡异报错都会变得清楚。我自己通常会在笔记里记录每次遇到的函数相关慢查询把现场 SQL、执行计划、最终改动写下来。做多了之后只扫一眼 WHERE 条件里的索引列是否被函数包裹大概就能判断这条 SQL 有没有优化空间。这种直觉不是天生的而是建立在一次次 EXPLAIN 和经验复盘之上的。下次再遇到奇怪的执行计划不妨先问自己一句这条查询里的函数到底是在哪个阶段被调用的想清楚了问题基本就解开了一半。 
长河君 · 2026/9/17 3:53:21 · 阅读 1.2k MySQL执行顺序与函数调用：如何避免索引失效的慢查询陷阱？
最近在排查一个生产环境慢查询时我发现了一个特别典型的现象一条三表联查 SQL数据量总共不过一百多万行其中一个核心表的过滤字段明明有索引执行计划却走了全表扫描。我盯着 EXPLAIN 看了好一会儿最后在 WHERE 条件里发现了罪魁祸首——一个将时间字段格式化成字符串再参与比较的 DATE_FORMAT 函数。函数本身完全没问题问题在于它出现的位置触发了执行顺序中最容易被忽略的一条规则WHERE 阶段是在条件匹配阶段逐行计算表达式的而这一步会直接切断 B 树索引的快速定位能力。这个案例恰好就是我想聊的主题MySQL 查询语句的执行顺序以及在查询过程中函数到底是怎么被调用的。理解这两个点不只是为了应付面试更是真实环境里优化慢查询、看懂执行计划、避免“看起来能走索引实际却走不了”的必备基本功。很多时候你觉得自己写的 SQL 和慢查询没关系但只要你理解执行顺序再回头看那些看似玄学的性能问题基本都能找到逻辑上的漏洞。1. 为什么执行顺序是 SQL 优化的第一课1.1 书写顺序与逻辑执行顺序的区别很多人在刚学 SQL 时就记住了标准写法SELECT 在最前面然后是 FROM、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT。这种书写顺序给人的错觉是数据库会从上到下读取语句先算 SELECT再算 FROM。这是最常见的误解之一。MySQL 的逻辑执行顺序并不是根据写 SQL 的顺序来的而是先确定数据来源再做行级过滤再做分组和聚合最后才做列的投影和排序。完整的逻辑顺序可以整理成下面这张表逻辑阶段核心动作常见误区FROM确定数据来源执行 JOIN生成虚拟结果集认为先执行 SELECT忽略了 JOIN 会产生笛卡尔积WHERE逐行过滤虚拟结果集不能使用聚合函数和别名误把聚合条件放在 WHERE 中导致语法报错GROUP BY按指定列分组为聚合函数计算做准备认为分组前就可以看到聚合结果HAVING对分组后的结果过滤可以使用聚合函数和 WHERE 混淆导致过滤时机错误SELECT计算列、表达式、函数生成最终结果列认为 SELECT 最先执行试图在 WHERE 里引用别名DISTINCT对结果去重忽略去重时机导致排序时数据集异常ORDER BY对最终结果排序没意识到排序发生在所有过滤和投影之后LIMIT限制返回行数以为 LIMIT 能减少之前的排序和扫描成本这个序列在教材里写过无数遍但真正会用它来思考问题的人并不多。比如一个经典报错在 WHERE 条件里引用了 SELECT 子句中定义的别名MySQL 直接报“Unknown column”很多新手第一反应是“列明明写了啊”。理解了执行顺序你就会明白WHERE 在 SELECT 投影之前执行别名在那个阶段根本不存在。反过来如果你在 HAVING 或 ORDER BY 里使用别名情况又不一样因为 HAVING 在 SELECT 之后才执行ORDER BY 更是靠后的阶段。1.2 每一步到底做了什么为了把抽象的顺序落到具体的操作上可以把这八个阶段想象成一条流水线。假设有订单表 orders、用户表 users 和订单明细表 order_items现在想统计每个用户的订单总金额只保留金额超过 1000 的统计结果最后按金额倒序展示前十条。这条 SQL 会先经过 FROM 把三张表关联起来生成一个包含用户信息和订单明细的中间数据集然后 WHERE 把无效订单、退货单或某些状态不对的行过滤掉接着 GROUP BY 按 user_id 分组HAVING 对分组后的总金额做二次过滤SELECT 阶段才算出来 SUM(order_items.amount) 这个表达式ORDER BY 再对 sum_amount 排序最后 LIMIT 10。从执行计划的角度看优化器并不一定严格按这个顺序重排但逻辑语义必须符合这条顺序。WHERE 中的条件越早过滤掉越多行后续参与分组和排序的数据量就越小这就是为什么我们要把选择性高的过滤条件放在 WHERE 中而不是全部丢给 HAVING。很多时候两条 SQL 写法不一样优化器最终生成的结果一致但因为书写方式影响了解析和优化成本导致执行计划完全不同。另外需要注意的是逻辑执行顺序中也存在部分重排的情况。MySQL 的优化器会把能合并的谓词下推会把子查询改写为半连接会在驱动表选择上做代价估算。所以不能仅凭逻辑顺序就对执行计划进行脑内推断而是要用 EXPLAIN 去验证。但逻辑顺序的价值在于帮你建立业务语义层面的直觉一个列别名能不能用一个聚合函数应该放在哪里一个函数调用到底会导致多少次计算都能从这个顺序里推出来。2. 执行顺序如何影响索引与连接策略2.1 WHERE 阶段慢查询的真实案例回到开头提到的那个慢查询案例。表结构大概是这样的一张订单流水表里面有一个 create_time 字段类型是 datetime上面建了索引。业务需求是查某一天的所有订单常规写法是 WHERE create_time 2024-01-01 00:00:00 AND create_time 2024-01-02 00:00:00。但同事写成了 WHERE DATE(create_time) 2024-01-01。从逻辑执行顺序来看WHERE 阶段要对每一行调用 DATE() 函数把 datetime 值转换为日期格式然后与常量比较。问题在于 DATE(create_time) 是一个以列作为参数的表达式MySQL 优化器很难把它直接反向推导成 create_time 的范围条件所以即便 create_time 上有索引也无法用来快速定位。整个查询就退化成全表扫描每条记录都要算一次函数性能自然直线下降。排查后把 SQL 改成范围写法执行计划从全表扫描 typeALL 变成了索引范围扫描 typerange查询耗时从 900 多毫秒降到了 30 毫秒以内。这里的关键不是 DATE() 函数本身慢而是函数参与表达式计算后切断了索引列与查询条件之间的等值或范围映射关系。理解这一点后当你看到 WHERE 条件里出现对索引列的函数包裹几乎可以直接判断这是一个潜在的性能雷。还有一个容易被忽略的问题是谓词顺序。在逻辑上WHERE 中的条件会尽可能早地使用但 MySQL 并不会严格按照书写顺序一个个判断优化器会按成本做条件重排。不过这并不意味着你可以随意乱写 WHERE 顺序毕竟优化器的能力有限复杂的函数表达式可能会阻碍它进行有效的条件排序导致过滤效果变差。2.2 ORDER BY 与 GROUP BY 的排序陷阱执行顺序对排序和分组的影响也很值得展开说。很多人以为 ORDER BY 只是最后排个序没什么技术含量。但如果 ORDER BY 的列上有索引MySQL 可以直接利用索引的有序性省掉 filesort而如果 ORDER BY 后面接了一个函数或表达式比如 ORDER BY RAND() 或 ORDER BY CONCAT(name, age)那么优化器通常只能生成结果集然后对所有数据做一次外部排序。GROUP BY 也一样。如果 GROUP BY 的列上有索引MySQL 可以按索引有序扫描边扫描边分组如果没有分组列索引或者 GROUP BY 中包含函数表达式就可能出现临时表和 filesort。这在执行计划里非常直观Extra 列如果出现了 Using filesort 或 Using temporary就说明在某个阶段存在额外的排序或临时表操作。另一个容易被忽略的问题是 ORDER BY 与 LIMIT 的组合。当 SQL 里同时出现 ORDER BY 和 LIMIT 时逻辑顺序是先排序再截断所以排序成本不会因为 LIMIT 而降低除非优化器能利用索引的有序性否则 MySQL 还是要先完成完整排序。这一点在高分页场景下特别明显OFFSET 很大时前边的排序和扫描成本全都要付出这也是为什么很多人会把深度分页优化为“返回上一页最大 id再做范围过滤”。2.3 JOIN 驱动顺序带来的“先过滤后关联”执行顺序里 FROM 阶段比 WHERE 早但在 JOIN 时优化器选驱动表和被驱动表的顺序会对性能产生巨大影响。逻辑上 JOIN 产生的是笛卡尔积后再过滤但实际 MySQL 在做嵌套循环连接时会优先选择结果集更小的表作为驱动表并且在驱动表扫描过程中就把适合下推的 WHERE 条件应用上。这就是为什么同一个 SQL只要 A 表和 B 表的角色互调执行计划就完全不同。从执行顺序的角度去理解 JOIN 的优化需要知道“过滤条件下推”这个概念。比如 WHERE 条件里同时涉及 A.id B.a_id 和 A.status 1如果 A 作为驱动表优化器会在扫描 A 时先用 status 1 过滤再拿结果去 B 表逐行匹配这样 B 表被访问的次数会少很多。相反如果条件写在 ON 里或者优化器选了错误的驱动表就可能导致被驱动表被反复扫描产生额外的扫描成本。这个过程里函数同样会捣乱如果 A.status 上用了函数驱动表的过滤无法走索引可能连优化器的统计信息都受影响后续 JOIN 顺序的选择也会出现偏差。3. MySQL 函数调用机制不止是写个函数那么简单3.1 函数在解析器、优化器、执行器中的流转函数调用机制的深入理解不能停留在“函数可以用在 SQL 里”这个层面。一条 SQL 从客户端发出到返回结果会经过连接器、解析器、优化器、执行器几个模块。解析器会先识别出 SQL 中的函数名校验函数是否存在、参数个数是否正确并把函数调用以节点形式挂到语法树上。优化器阶段函数是否可被下推、是否会被多次计算会直接参与优化决策。执行器阶段函数才真正被逐行调用。一个常见的疑问是“SELECT NOW() 中的函数会被调用几次”理论上如果 NOW() 在 SELECT 列表里对多行结果调用MySQL 会保证它在同一条 SQL 执行期间返回一致的结果因为 NOW() 是语句级时间函数。但如果是 RAND()那每一行都可能得到不同的随机值如果是用户自定义函数或存储函数要看你有没有在函数内部访问表数据或者使用随机数、系统时间等变量。MySQL 对函数大致分为确定性的和非确定性的非确定性函数会让优化器更谨慎甚至在复制场景下产生主从不一致风险。函数调用发生的阶段与执行顺序是绑定的。你在 WHERE 中写了一个自定义函数执行器就会对每一行调用一次你在 SELECT 列表中写的函数则是对每一条投影后的行调用。若函数出现在 HAVING 中调用次数则等于分组数量。这种调用时机的差异直接决定了函数对性能的影响范围。比如 WHERE 条件里有一个耗时的自定义函数数据量一上来函数调用的累计消耗会非常惊人但如果把它挪到最后的 SELECT 投影中影响范围就只集中在最终返回的那些行上。3.2 存储函数、DETERMINISTIC 与复制安全MySQL 里可以创建存储函数也就是用户定义的 SQL 函数。创建时需要指定 DETERMINISTIC 等属性。很多人创建存储函数时不写 DETERMINISTIC或者写 NO SQL、READS SQL DATA以为无所谓。实际上这会带来两个问题。第一个问题是优化限制。如果一个函数是非确定性的比如内部用了 RAND()、UUID() 或者 GET_LOCK()那么优化器无法判断它在两次执行之间是否会改变结果因此某些优化措施会被禁用。查询中如果非确定性函数出现在 WHERE 条件中对索引列进行计算那么这条查询基本没有机会使用索引。第二个问题是复制安全。在主从架构下如果存储函数修改了数据又没有正确声明 DETERMINISTIC那么从库在重放 binlog 时可能产生不一致的结果。MySQL 官方文档要求用户对自定义函数做出准确声明否则复制的可靠性就没有保障。我见过一个比较典型的例子有人写了一个获取当前月份的函数内部用了 CURDATE()然后在查询条件里用这个函数去比较订单月份。因为非确定性函数的参与这个查询无法被优化器长期缓存执行计划每次执行计划都要重新生成同时 WHERE 条件对索引列的函数包裹又造成索引失效。最终解决方案很简单把函数调用挪到应用层先算出具体的月份值再作为常量传入 SQL。这样既保留了业务逻辑的清晰度也避开了函数对优化器的影响。3.3 函数副作用与索引失效的隐雷除开性能函数副作用也值得单独说。所谓副作用就是函数除了返回值之外还修改了外部状态比如修改会话变量、临时表或者调用了 RAND() 导致结果不稳定。这类函数一旦写入 WHERE 条件就可能出现同一条 SQL 两次执行返回不同行数或者执行计划不稳定的情况。最常见的隐雷是隐式类型转换。当函数不是显式出现而是由 MySQL 自动触发时很多人根本发现不了。例如一个 varchar 类型的手机号字段如果你拿它和数字类型比较MySQL 会自动调用 CAST 把 varchar 转成数字相当于对索引列应用了隐式函数。我排查过一个诡异问题手机号注册数量统计时某几条记录被漏掉排查到最后一查执行计划发现查询里用了 phone 13800000000 的写法MySQL 把字符串列转成数值比较遇到非纯数字的号码就出现了不匹配。这一类隐式转换在 EXPLAIN 中不会显示你写的函数但 type 列往往直接从 range 掉到 ALL基本就能判断出来。还有一类容易踩的坑是在 ORDER BY 中使用函数。比如你要对备注字段去除前后空格后排序写成 ORDER BY TRIM(remark)这个操作本身没问题但会让有序索引完全失效。更好的做法是在应用层预处理字段或者使用 MySQL 5.7 之后支持的生成列把 TRIM(remark) 的结果固化到一个虚拟列中并在该虚拟列上建索引。这样既能保留业务语义的清晰性又能继续享受索引带来的有序扫描优势。4. 实战排查当执行顺序与函数机制碰撞在一起4.1 常见报错速查与根因分析说到执行顺序与函数机制碰撞最直接的反馈就是一串串报错。我把实际工作中高频出现的几类问题整理成一个速查表报错信息根因分析解决建议Unknown column alias in where clauseWHERE 阶段无法识别 SELECT 别名改用原始列名或在外层查询再过滤Invalid use of group function聚合函数出现在 WHERE 中而 WHERE 不执行聚合逻辑将聚合条件移到 HAVING或改写为子查询Illegal mix of collations函数返回的字符集与表列字符集不一致显式指定 COLLATE或统一字符集和排序规则This function has none of DETERMINISTIC...创建存储函数时缺少必要属性声明根据实际语义补充 DETERMINISTIC / NO SQL 等Table xxx is specified twice子查询和外层查询引用了同名表导致关联歧义给表起别名明确引用关系这里要特别强调“聚合函数出现在 WHERE 中”这个错误。逻辑执行顺序里WHERE 是在 GROUP BY 之前执行的它只能处理原始行根本看不见聚合结果。所以 where count(*) 1 必然报错。如果你真的需要过滤分组之后的结果要么用 HAVING要么把聚合结果放到子查询里再在外层用 WHERE 过滤。理解了顺序这类报错基本不需要查文档。还有一个容易被忽略的报错是函数参数类型不匹配。比如某个函数传入了 NULL 值导致整个表达式返回 NULL进而影响筛选结果。在 MySQL 中很多函数遇到 NULL 会返回 NULL而不是报错或返回空字符串这会让业务逻辑变得很隐蔽。排查时要特别注意 WHERE 条件里函数对 NULL 的处理方式否则很容易出现“为什么这条记录没查出来”的疑惑。4.2 通过执行计划定位函数导致的性能瓶颈排查函数调用导致的性能问题EXPLAIN 是最好的切入点。在 MySQL 8.0 里我一般先执行 EXPLAIN ANALYZE它会输出每一步实际执行的时间、行数和循环次数。这一步对定位“函数是不是在循环里被反复调用”特别有帮助。举个例子执行计划中如果出现 Using where说明有额外的条件过滤而这个过滤很可能就发生在无法用索引快速定位的情况下。此时再观察 rows 列如果 rows 预估很大但最终输出结果很少往往就是函数或表达式让优化器没法利用统计信息。进一步用 EXPLAIN ANALYZE 看 actual rows 和 actual time你会发现每一行都要调用一次表达式计算循环次数巨大而这正是函数调用机制与执行顺序结合的现场。还有一个技巧用 optimizer trace 看优化器最终选择了哪条路径。在 MySQL 中设置 optimizer_traceenabledon再执行查询然后查询 INFORMATION_SCHEMA.OPTIMIZER_TRACE就能看到优化器是否尝试过索引合并、是否把条件下推、是否将子查询转换为半连接。遇到奇怪的性能问题时它比 EXPLAIN 更能还原决策过程。不过 optimizer trace 输出很冗长需要抓关键字段比如 considered_execution_plans 里的 cost 变化以及 condition_processing 里的 predicate 下推情况。4.3 生产环境优化建议清单结合执行顺序和函数调用机制我在生产环境里的优化建议可以归纳成一条可操作的清单优先保证 WHERE 条件中的索引列保持“裸列”任何对列的函数包裹都会增加优化器推导范围条件的难度。如果业务必须按日期过滤写成范围条件必须按年、月过滤考虑生成列。SELECT、ORDER BY、GROUP BY 中的函数尽量在应用层完成。让数据库只承担存储和必要的数据处理把字符串格式化、日期计算放到后端服务里既能降低数据库 CPU也让 SQL 更容易走索引。使用存储函数时准确声明 DETERMINISTIC、NO SQL 或 READS SQL DATA。声明后优化器才有可能对函数结果做常量折叠或缓存也能降低复制风险。对高频使用的函数表达式比如 DATE(order_time)、YEAR(create_time)可以建立生成列并加索引。MySQL 5.7 引入了生成列8.0 支持索引虚拟列可以让“看起来无法用索引的查询”重新走上索引路径。在深度分页场景里用“上一页最大 ID”替换 OFFSET LIMIT避免 LIMIT 阶段之前必须完成全量排序的问题。每次新 SQL 上线前至少跑一次 EXPLAIN重点看 type 是否达到了 range 或 refExtra 里是否出现了 Using filesort 或 Using temporary。5. 一些当排坑后的个人体会聊了这么多其实我想表达的核心就一句话MySQL 的执行顺序和函数调用机制不是互相独立的概念。函数调用到底发生在哪个执行阶段决定了它对索引和性能的影响方式而执行顺序又决定了函数能不能被识别、能不能被下推、能不能被缓存。多想想这两个问题很多“玄学”慢查询和诡异报错都会变得清楚。我自己通常会在笔记里记录每次遇到的函数相关慢查询把现场 SQL、执行计划、最终改动写下来。做多了之后只扫一眼 WHERE 条件里的索引列是否被函数包裹大概就能判断这条 SQL 有没有优化空间。这种直觉不是天生的而是建立在一次次 EXPLAIN 和经验复盘之上的。下次再遇到奇怪的执行计划不妨先问自己一句这条查询里的函数到底是在哪个阶段被调用的想清楚了问题基本就解开了一半。