优化器可能选择错误的执行计划

有很多种原因会导致 MySQL 优化器选择错误的执行计划，如下所示：

• 统计信息不准确

  MySQL 服务器依赖存储引擎提供的统计信息来评估成本，但是有的存储引擎提供的信息是准确的，有的偏差可能非常大。

  例如，InnoDB 因为其 MVCC 的架构，并不能维护一个数据表的行数的精确统计信息。

• 成本指标并不完全等同于运行查询的实际成本

  即使统计数据是准确的，实际的查询成本也可能超过或者低于 MySQL 估算的近似值。

  例如，有时候某个执行计划虽然需要读取更多的页面，但是它的成本却更低。因为如果这些页面都是顺序读或者这些页面都已经在内存中的话，那么它的访问成本将很低。MySQL 并不知道哪些页面在内存中、哪些在磁盘中，所以查询在实际执行过程中到底需要多少次物理 I/O 是无法得知的。

• MySQL 的最优可能和你想的最优不一样

  你可能希望执行时间尽可能短，但是 MySQL 只是基于其成本模型选择最优的执行计划，而有些时候这并不是最快的执行方式。所以，这里我们看到的根据执行成本来选择执行计划并不是完美的模型。

• MySQL 从不考虑其他并发执行的查询，这可能会影响到当前查询的速度

• MySQL 并不是任何时候都是基于成本的优化，它有时也会基于一些固定的规则

  例如，如果存在全文搜索的 MATCH() 子句，则在存在 FULLTEXT 索引的时候就使用全文索引。即使有时候使用其他索引和 WHERE 条件可以远比这种方式要快，MySQL 也仍然会使用对应的全文索引。

• MySQL 不会考虑不受其控制的操作的成本

  例如，执行存储函数或者用户自定义函数的成本。

• 优化器有时候无法估算所有可能的执行计划，所以它可能错过实际上最优的执行计划