我正在优化我的MySQL数据库中的查询过程。在使用Visual Explain并查看各种查询成本时，我反复找到反直觉的值。使用更有效的查找（例如，密钥查找）的操作似乎具有比表面上效率较低的操作（例如全表扫描或全索引扫描）更高的查询成本。查询成本是MySQL查询优化的最佳指标吗？
这方面的例子甚至可以在MySQL手册中可以看出，在一节有关的Visual Explain上this page： 
为全表扫描查询的成本是基于密钥的查找查询费用的一小部分。我在我自己的数据库中看到完全相同的场景。
所有这些对我来说都是完全倒退的，并引发了这样一个问题：在优化查询时，我应该使用查询成本作为标准吗？或者我从根本上误解了查询成本？
一个例子：
你有1000个法语单词和法语的英语（非电子）词典列表。你的任务是创建一个包含1000个法语单词和他们的英文翻译的表格。
第一步：将列表中的法语单词写入表格的第一列。
第二步：查找字典中每个单词的翻译并将它们写入第二列。
您认为哪一步需要更长时间？
MySQL没有与优化有关的很好的度量标准。其中一个更好的是EXPLAIN FORMAT=JSON SELECT ...，但它有点神秘。
一些 '严重' 的漏洞：
LIMIT。我喜欢这个，因为它让我比较两个配方/索引/等等，甚至对小的表在计时基本是没用的：
FLUSH STATUS;
perform the query
SHOW SESSION STATUS LIKE "Handler%";
它提供确切计数（不像EXPLAIN）的读取，写入（临时表）等等。它的主要缺陷在于没有区分读/写需要多长时间（由于缓存，索引查找等）。然而，它通常非常擅长指出查询是否执行了表/索引扫描与查找与多次扫描。
在一天结束时，“实际表现”通常是最重要的。估计（和实际）查询计划是很好的。另一方面，让相关查询快速运行通常是一项要求。 – user2864740
另外，我不确定问题在问什么 - 基本FTS的成本本身是没有意义的，因为它只是回答查询所需信息的一部分。（如果表有适当的索引和数据量，它应该从全扫描变为索引扫描：这一步实际上只是“建立最初的N [1000]行”。在这种情况下，计划员认为表格足够小或没有可用的索引。） – user2864740
我明白查询的每一步都在做什么以及它是如何做的。我不明白的是，几乎没有例外，查询规划师认为索引读取比非索引读取更昂贵，否则常识会告诉你。例如，在我的数据库中，我发现一个查询执行全表扫描，因此我添加了一个适当的索引，然后计划人员选择了该索引，但EXPLAIN显示查询成本在该更改后变为** **。 –