1.1     optimizer_search_depth参数

以上提到的greedy_search+best_extension_by_limited_search函数，通过search_depth参数控制递归调用的深度。而search_depth参数，可通过optimizer_search_depth来设置。

一般而言，如果optimizer_search_depth设置过大，那么join时，获取最优执行计划的代价十分巨大。

optimizer_search_depth = join tables的数量，一定能获得最优执行计划(根据mysql的代价估计模型)，但是计算代价大。

optimizer_search_depth < join tables的数量，获取的执行计划，是局部最优，但是计算代价小。

optimizer_search_depth参数，对于单表查询无意义。

http://dev.mysql.com/doc/refman/5.0/en/controlling-optimizer.html中，有mysql对于此参数的说明，可以参考。

1.2     多表join查询总结

• join的查询优化，是一个复杂的过程。
• mysql在join的查询优化中，同样为指定unique查询的sql做了优化，优化方案与单表unique查询类似：若发现指定的unique无法找到匹配的记录，直接返回，而不产生真正的执行计划，如下图所示：

当mysql查询优化发现nkeys.c2 = 20无法匹配到记录，直接返回。并不会继续生成完整的执行计划。

• 在best_access_plan函数中，对表s进行最优路径选择时，会充分利用range查询优化的结果。若无法利用range查询优化结果，还会使用的统计信息包括：

(1).rec_per_key

每一个key，包含多少记录。在存储引擎，info函数中进行收集。

(2).records_in_table

当前表上，有多少记录。在存储引擎，info函数中进行收集。

• 对于多表join查询，rec_per_key, records_in_table两个统计信息相当重要，直接影响到最后的执行计划选择。因此在引擎实现中，要充分考虑这两个统计信息的收集算法。如果能够持久化这两个统计信息，就基本上能够保证join查询的执行计划稳定。
• 下一章节，将分析INNODB如何收集records_in_table，rec_per_key这两个统计信息。

本系列文章主目录：MySQL数据库InnoDB存储引擎查询优化器实现的分析

建议继续学习：

1. Mysql查询优化器浅析（上）    (阅读：2557)
2. MySQL数据库InnoDB存储引擎查询优化器实现的分析之单表查询    (阅读：2531)
3. Mysql查询优化器浅析（下）    (阅读：2112)
4. MySQL数据库InnoDB存储引擎查询优化器实现的分析之单表unique查询    (阅读：2167)
5. MySQL数据库InnoDB存储引擎查询优化器实现的分析    (阅读：2032)
6. MySQL数据库InnoDB存储引擎查询优化器实现的分析之多表简单JOIN查询    (阅读：2112)
7. MySQL数据库InnoDB存储引擎查询优化器实现的分析之附录    (阅读：1907)
8. MySQL数据库InnoDB存储引擎查询优化器实现的分析之统计信息    (阅读：1704)
9. MySQL数据库InnoDB存储引擎查询优化器实现的分析之best_access_path函数分析    (阅读：1598)