10bet网址
MySQL 5.7参考手册
相关文件10bet官方网站 下载本手册 从本手册中摘录

8.9.1控制查询计划评估

查询优化器的任务是找到执行SQL查询的最佳计划。因为之间的性能差异好的坏的计划可以是数量级(即秒,几小时甚至几天),大多数查询优化器,包括MySQL,在所有可能的查询评估计划中对最佳计划进行更多或更少的详尽搜索。对于加入查询,MySQL Optimizer调查的可能计划的数量以查询中引用的表数指数呈指数级呈指数级。对于少数表(通常小于7到10),这不是问题。但是,当提交更大的查询时,查询优化所花费的时间可能很容易成为服务器性能中的主要瓶颈。

一种更灵活的查询优化方法使用户能够控制优化器的搜索方面如何详尽的优化查询评估计划。一般思想是,优化器调查的计划越小,在编译查询时花费的时间越少。另一方面,由于优化器跳过一些计划,可能会错过找到最佳计划。

可以使用两个系统变量来控制优化器关于它评估的计划数的行为:

  • Optimizer_Prune_Level.变量告诉优化器根据对每个表访问的行数的估计来跳过某些计划。我们的经验表明这种情况有根据的猜测很少错过最佳计划,并可能会大大减少查询编译时间。这就是此选项所在的原因(Optimizer_Prune_Level = 1) 默认。但是,如果您认为优化器错过了更好的查询计划,则可以关闭此选项(Optimizer_Preune_Level = 0.)查询编译可能需要更长时间的风险。注意,即使使用这种启发式,优化器仍然探讨了大致指数的计划数。

  • Optimizer_Search_depth.变量讲述了多远未来每个不完整的计划中,优化器应该寻求评估它是否应该进一步扩展。较小的值Optimizer_Search_depth.可能导致数量级较小的查询编译时间。例如,具有12,13或更多表的查询可能很容易需要数小时甚至天数来编译Optimizer_Search_depth.接近查询中的表数。同时,如果编译Optimizer_Search_depth.等于3或4,优化器可以在不到一分钟内编译相同的查询。如果你不确定合理的价值是什么Optimizer_Search_depth.,可以将此变量设置为0以告知优化器自动确定值。