MySQL BENCHMARK 的循环耗时为什么不能代替整条查询耗时

如果你把 SELECT BENCHMARK(N, expr) 的耗时，直接当成整条 SQL 的执行耗时，结论很容易失真。BENCHMARK() 的作用是反复执行一个标量表达式；而一次完整的 SELECT 还可能包含客户端通信、解析、优化器、表访问、锁处理和结果集传输。两者测量的不是同一段工作。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/information-functions.html

排查这类差异时，先把问题改写成“我到底要测表达式运行时，还是要测一条真实查询的端到端表现”。前者可以用 BENCHMARK，后者应回到真实 SQL、执行计划、客户端耗时和生产观测。

问题现场：为什么两个耗时差很多

常见场景是：开发者先用一条完整查询观察耗时，再把其中的函数表达式放进 BENCHMARK()，希望通过增加循环次数得到更稳定的数字。结果往往是循环平均值与原查询耗时完全对不上，于是误以为 MySQL 的计时不可靠。

先看结构而不是看数字：完整查询是一条更长的路径，BENCHMARK() 是在这条路径中截取运行时表达式部分并重复执行。截取后的数字当然可能更小，也可能因为缓存、负载和表达式特性呈现不同波动。

初步判断：BENCHMARK 到底测了什么

MySQL 官方文档把 BENCHMARK(count, expr) 定义为重复执行表达式 expr count 次。它只接受标量表达式；如果表达式中的子查询返回多列或多行，就不符合这个使用边界。

例如，下面的示意语句适合观察某个纯表达式在重复计算时的相对表现：

-- 只观察标量表达式重复计算，不把整条查询的路径混进来。
SELECT BENCHMARK(1000000, SHA2('demo-value', 256));

客户端看到的时间仍是端到端的 elapsed time，不是服务器 CPU 时间。这个时间可以帮助你比较表达式在当前环境中的趋势，但不能单独回答“线上这条查询为什么慢”。

动手验证：把两种测量路径拆开

接下来不要把两条语句的数字硬做换算，而是先列出它们各自包含的环节。完整 SELECT 通常要经历 SQL 文本接收、解析、优化、表访问或其他执行组件，并把结果交给客户端；BENCHMARK() 则让解析和优化等环节发生一次，再偏重重复表达式的运行时。

定位原因：完整查询的哪些部分被省略了

官方文档特别提醒：重复执行 SELECT expr，与执行 SELECT BENCHMARK(N, expr) 有不同的开销。前者每次都可能重新经过解析器、优化器、表锁和运行时评估；后者把这些前置环节做一次，把重复权重放在运行时评估上。

这意味着下面两类问题不能靠 BENCHMARK 单独判断：

• 查询是否选错索引、扫描了过多行，或连接、排序、分组带来了主要成本；
• 客户端网络、返回行数、锁等待、并发负载或缓存状态是否造成端到端变慢。

如果原查询有表访问和结果集返回，建议先单独看真实 SQL 的计划和返回规模；如果你只是比较两个字符串函数、日期函数或加密表达式，BENCHMARK 才更接近问题本身。

修复方案：怎样设计一组可解释的对比

第一步是固定表达式，让每轮只改变一个变量；第二步是固定循环次数和连接环境；第三步是多次执行并记录当时的服务器负载；第四步是明确你要比较的是相对趋势，不是把一个局部数字换算成整条 SQL 的耗时。

-- 让两次测试只改变待比较的表达式，次数和输入保持一致。
SELECT BENCHMARK(500000, SHA2('value-a', 256));

-- 对第二个候选表达式使用同样的次数，避免把循环规模当成结论。
SELECT BENCHMARK(500000, SHA2('value-b', 256));

需要判断整条查询时，保留原始 SQL，结合 EXPLAIN 或其他适合你版本与场景的执行观测工具，观察访问路径、过滤规模和返回行数。不要为了让两种测试“看起来一致”，在 BENCHMARK 里伪造表扫描、网络返回或并发等待。

验证结果：什么时候可以相信 BENCHMARK 的结论

当问题边界是“某个标量表达式 A 和 B 哪个运行时更重”时，BENCHMARK 可以作为局部对比工具。你需要多次测量，并根据机器负载解读结果；缓存和已经分配的内存结构也可能改变表现。

当问题边界是“这条业务 SQL 为什么慢”时，BENCHMARK 只能解释其中一个表达式，不能代替完整查询观测。最终结论至少要回到真实 SQL 的执行路径、客户端观察到的耗时和当前负载背景。

常见问题：BENCHMARK 与完整查询耗时

BENCHMARK 的结果能不能除以循环次数得到函数耗时？

只能把它当作非常粗略的平均趋势，不能视为一次独立函数调用的精确成本。循环本身、缓存和客户端计时都会影响结果。

为什么完整 SELECT 反而比 BENCHMARK 更快？

两者执行路径不同，且缓存、优化和返回结果规模都可能影响观测。不要只根据单次数字判断，先确认两条语句测量的对象是否相同。

BENCHMARK 能测带表查询吗？

它的参数要求是标量表达式；涉及多行、多列或完整表访问的业务查询，不适合用 BENCHMARK 代替真实查询基准。

线上慢查询应该先看什么？

先保留真实 SQL 和参数边界，再看执行计划、返回规模、锁与等待、客户端耗时和并发背景。只有确认瓶颈落在某个表达式运行时，才用 BENCHMARK 做局部比较。

一句话总结：BENCHMARK() 负责把一个标量表达式重复跑起来，完整查询耗时则包含更多语句级和环境级开销；前者能帮助你比较局部运行时，不能替代后者的性能结论。