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存储引擎查询优化器实现的分析