读《高性能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 不会考虑不受其控制的操作的成本。