MySQL 查询的成本的查看

读《高性能MySQL》第三版，笔记。

MySQL 使用基于成本的优化器，它将尝试预测一个查询使用某种执行计划时的成本，选择其中成本最小的一个。

最初，成本的最小单位是随机读取一个 4K 数据页的成本，后来（成本计算公式）变得更加复杂，并且引入了一些 “ 因子 ” 来估算某些操作的代价，如当执行一次 WHERE 条件比较的成本。

可以通过查询当前会话的 last_query_cost 的值来得知 MySQL 计算的当前查询的成本。

mysql> show status like 'last_query_cost';
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| Last_query_cost | 2.399000 |
+-----------------+----------+
1 row in set (0.00 sec)

以上表示需要 2 个数据页的随机查询才能完成上面的查询。

这是根据一系列的统计信息计算得来的：

• 每个表或者所有的页面个数
• 索引的基数（索引中不同值的数量）
• 索引和数据行的长度
• 索引分配情况

优化器评估成本不考虑缓存，它假设读取任何数据都需要一次磁盘 I/O。

有很多原因会导致 MySQL 优化器选择错误的执行计划：

• 统计信息不准确。
• 执行计划中的成本估算不等同于实际执行的成本。
• MySQL 的最优可能和你想的最优不一样。
• MySQL 从不考虑其他并发执行的查询，这可能会影响到当前查询的速度。
• MySQL 也并不是任何时候都是基于成本的优化。
• MySQL 不会考虑不受其控制的操作的成本。