查询成本是 MySQL 查询优化的最佳指标吗？
Hay*_*ech 5 mysql query-optimization
我正在优化我的 MySQL 数据库中的查询。在使用 Visual Explain 并查看各种查询成本时，我反复发现违反直觉的值。使用更高效查找的操作（例如键查找）似乎比表面上效率较低的操作（例如全表扫描或全索引扫描）具有更高的查询成本。
这个例子甚至可以在 MySQL 手册中看到，在这个页面上关于 Visual Explain 的部分：
全表扫描的查询成本是基于键查找的查询成本的一小部分。我在自己的数据库中看到了完全相同的场景。
所有这一切都向后似乎完全给我，并提出这样的问题：我应该使用的查询成本的标准优化查询时？还是我从根本上误解了查询成本？
MySQL 没有非常好的与优化相关的指标。更好的之一是EXPLAIN FORMAT=JSON SELECT ...，但它有点神秘。
一些“严重”缺陷：
- 很少有任何事情可以解释
LIMIT。 - 指数的统计是粗略的，不允许分布不均。（直方图“即将”推出。）
- 关于当前是否缓存数据/索引，以及您是否拥有旋转驱动器或 SSD，我们几乎没有采取任何措施。
我喜欢这个，因为它让我可以比较两个公式/索引/等，即使对于计时几乎无用的小表：
FLUSH STATUS;
perform the query
SHOW SESSION STATUS LIKE "Handler%";
它提供了读取、写入（临时表）等的精确计数（与 不同EXPLAIN）。它的主要缺陷是不区分读取/写入花费的时间（由于缓存、索引查找等）。然而，它通常非常擅长指出查询是进行表/索引扫描、查找还是多次扫描。
正则表达式EXPLAIN无法指出多种排序，例如GROUP BY and ORDER BY可能发生的情况。并且“使用文件排序”并不一定意味着将任何内容写入磁盘。