查询成本是MySQL查询优化的最佳指标吗？

我正在优化MySQL数据库中的查询。在使用VisualExplain和查看各种查询成本的同时，我反复发现了与直觉相反的值。使用更高效的查找（例如键查找）的操作似乎比表面上效率较低的操作（例如全表扫描或全索引扫描）具有更高的查询成本

这方面的例子甚至可以在MySQL手册中看到，在关于以下内容的VisualExplain部分： 全表扫描的查询成本是基于键查找的查询成本的一小部分。我在自己的数据库中看到了完全相同的场景

---

所有这些在我看来都是完全倒退的，并提出了一个问题：在优化查询时，我是否应该使用查询成本作为标准？还是我从根本上误解了查询成本？

MySQL没有很好的优化指标。其中一个更好的方法是

EXPLAIN FORMAT=JSON SELECT…

，但它有点神秘

一些“严重”缺陷：

• 很少有什么能解释

  限制

• 关于指数的统计数据是粗糙的，不允许分布不均。（直方图很快就会出现。）
• 对于当前是否缓存数据/索引，我们所做的很少，对于是否有旋转驱动器或SSD，我们所做的也很少

我喜欢这一点，因为它可以让我比较两个公式/索引/etc，即使对于计时几乎毫无用处的小表：

FLUSH STATUS;
perform the query
SHOW SESSION STATUS LIKE "Handler%";

它提供读取、写入（到临时表）等的精确计数（与解释不同）。它的主要缺陷在于无法区分读取/写入所用的时间（由于缓存、索引查找等）。但是，它通常非常擅长指出查询是否进行了表/索引扫描、查找还是多次扫描

---

常规的

EXPLAIN

无法指出多种排序，例如

groupby

和

orderby

可能发生的排序。“使用文件排序”并不一定意味着任何东西都会写入磁盘。

一天结束时，“实际性能”通常是最重要的。。估计的（和实际的）查询计划很好。另一方面，快速运行相关查询通常是一项要求。此外，我不确定问题是什么——基本FTS的成本本身毫无意义，因为它只是回答查询所需信息的一部分。（如果表具有适当的索引和数据量，则应将其从完全扫描更改为索引扫描：此步骤实际上只是“构建初始N[1000]行”。在这种情况下，规划人员认为表足够小或没有可用的索引。）我了解查询的每个步骤都在做什么以及它是如何做的。我不明白的是，几乎无一例外，查询规划者认为索引读取比非索引读取更昂贵，而常识会告诉你不是这样。例如，在我的数据库中，我发现一个查询正在进行全表扫描，因此我添加了一个适当的索引，然后计划员选择了该索引，但解释显示，在该更改之后，查询成本增加了。