可能导致mysql优化器选择错误的执行计划的原因如下：
A：统计信息不准确，mysql依赖存储引擎提供的统计信息来评估成本，但有的存储引擎提供的信息是准确的，有的引擎提供的可能就偏差很大，如：innodb因为其MVCC的架构，并不能维护一个数据表的行数的精确统计。
B：执行计划中的成本估算不等同于实际执行的成本，所以即使统计信息精准，优化器给出的执行计划也可能不是最优的，如：有时候某个执行计划虽然需要读取更多的页，但它的实际执行成本却更小，因为如果这些页面都是顺序或者这些页面都在内存中，那么它的访问成本将小很
多。mysql层面并不知道哪些页面在内存中，哪些在磁盘上，所以查询实际执行过程中到底需要多少次物理IO是无法预估的。
C：mysql的最优可能和你觉得最优的不一样，你可能希望执行时间尽可能地短，但是mysql只是基于成本模型选择最优执行计划，而有些时候这并不是最快的执行计划（因为mysql的成本估算主要基于扫描行数，而如果这些行是顺序的或者是在内存中，那么扫描速度就会很快，相反，如果这些行是在磁盘上且是无序的，就会产生随机读取，那么就算扫描更少的行，可能执行时间更长，而优化器在评估成本的时候并不考虑任何层面的缓存，它假设读取任何数据都需要一次磁盘IO）。
D：mysql从不考虑其他并发执行的查询，这可能影响到当前查询的速度
E：mysql也并不是任何时候都是基于成本优化，有时候也会基于一些固定的规则，如：如果存在全文搜索的match()子句，则在存在全文索引的时候就使用全文索引，即使有时候使用别的索引和where条件可以远比这种方式快，mysql也仍然使用对应的全文索引。
F：mysql不会考虑不受控制的操作成本，如：执行存储过程或者用户自定义函数的成本
G：优化器有时候无法去估算所有可能的执行计划，所以它可能错过实际上最优的执行计划。