8
MySQL数据库InnoDB存储引擎查询优化器实现的分析之optimizer_search_depth参数
source link: https://blogread.cn/it/article/4769?f=hot1
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
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存储引擎查询优化器实现的分析
建议继续学习：
QQ技术交流群：445447336，欢迎加入！
扫一扫订阅我的微信号：IT技术博客大学习
扫一扫订阅我的微信号：IT技术博客大学习
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK