技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> MySQL --> MySQL数据库InnoDB存储引擎查询优化器实现的分析之optimizer_search_depth参数

MySQL数据库InnoDB存储引擎查询优化器实现的分析之optimizer_search_depth参数

浏览:1912次  出处信息

 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查询优化器浅析(上)    (阅读:2539)
  2. MySQL数据库InnoDB存储引擎查询优化器实现的分析之单表查询    (阅读:2486)
  3. Mysql查询优化器浅析(下)    (阅读:2096)
  4. MySQL数据库InnoDB存储引擎查询优化器实现的分析之单表unique查询    (阅读:2108)
  5. MySQL数据库InnoDB存储引擎查询优化器实现的分析    (阅读:1982)
  6. MySQL数据库InnoDB存储引擎查询优化器实现的分析之多表简单JOIN查询    (阅读:2028)
  7. MySQL数据库InnoDB存储引擎查询优化器实现的分析之附录    (阅读:1861)
  8. MySQL数据库InnoDB存储引擎查询优化器实现的分析之统计信息    (阅读:1659)
  9. MySQL数据库InnoDB存储引擎查询优化器实现的分析之best_access_path函数分析    (阅读:1556)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1