mariadb直到10.4版本才有Optimizer Trace， 之前的版本执行'SET optimizer_trace='enabled=on'; '会返回错误

mariadb知道10.4版本才有Optimizer Trace， 之前的版本执行'SET optimizer_trace='enabled=on'; '会返回错误
https://mariadb.com/resources/blog/optimizer-trace-in-mariadb-server-10-4/
One of the new features in MariaDB Server 10.4 is the Optimizer Trace. It provides diagnostics about the optimizer: you can switch the tracing on, run a statement, and then examine the trace to see how the optimizer processed the statement and arrived at the query plan.

MariaDB Server 10.4中的一项新功能是Optimizer Trace。它提供有关优化器的诊断：您可以打开跟踪、运行语句，然后检查跟踪以查看优化器如何处理语句并到达查询计划。

这与其他查询优化器工具（例如EXPLAIN和ANALYZE for statements）有什么关系？它非常适合：EXPLAIN [FORMAT=JSON] 显示优化器选择的查询计划。ANALYZE [FORMAT=JSON] 允许它查看执行查询计划时发生的情况。现在，优化器跟踪允许查看在查询优化阶段发生了什么：

从优化器跟踪内容中可以学到什么？

第一个例子是潜在的查询计划。根据我的经验，关于优化器的最常见且最难回答的问题之一是：为什么优化器没有选择某个查询计划？看起来这将是一个不错的选择。甚至考虑过那个查询计划吗？如果不是，为什么？如果是，预期成本是多少？优化器是否因为索引统计信息使它看起来很差而丢弃它？收集更多统计数据会有帮助吗？在优化器跟踪之前，需要查看源代码和/或进行大量猜测。现在，可以从踪迹中得到明确的答案。

我发现另一个特别有用的用例是抱怨在一个系统上选择了一个查询计划，而在不同的系统上选择了另一个查询计划。这些系统通常几乎相同，除了一些“无害的”更改，例如添加/删除的列、更改的字符集或服务器版本之间的微小差异。如果没有优化器跟踪，找出差异的原因可能会非常耗费人力，并且需要访问这两个系统。使用优化器跟踪，只需比较跟踪并立即查看差异开始的位置。

第三个用例是寻求帮助。对于那些不以调试数据库性能问题为生的人来说，优化器跟踪内容可能看起来有点神秘，但它为那些以调试为生的人提供了很多有用的信息。现在，如果有一个行为不端的查询，保存跟踪和请求帮助会容易得多。跟踪内容是人类可读的，因此可以确保它们没有发送任何敏感数据。我认为，使用跟踪对优化器问题进行故障排除将变得更加容易。

最后一个要分享的项目。如果您想在升级到 MariaDB Server 10.4之前使用优化器跟踪功能，现在可以。Optimizer Trace 将向后移植到 MariaDB Enterprise Server 10.3。