zoukankan      html  css  js  c++  java
  • 8.9.1 Controlling Query Plan Evaluation 控制查询评估

    8.9 Controlling the Query Optimizer

    8.9.1 Controlling Query Plan Evaluation
    8.9.2 Controlling Switchable Optimizations
    8.9.3 Index Hints

    MySQL 通过控制系统变量来影响 查询计划的评估,切换优化器,和index 提示

    8.9.1 Controlling Query Plan Evaluation 控制查询评估

    查询计划的任务 是找到最优化的计划用于执行查询。

    因为在好和坏的性能区别可以是数量级的(即,秒和数小时甚至数天),

    大多数的查询优化, 包括MySQL ,执行一个或多或少的彻底的搜索用于一个优化的执行计划

    对于关联查询, MySQL 优化器调查的可能的执行计划的数量呈指数级增长的查询中引用的表的数量。

    对于小的数量的表(通常小于7到10) 这个不是问题。

    然而, 当一个大的查询被提交, 查询优化器花费的时间可能会成为主要的瓶颈

    一个更加灵活的方法用于查询优化, 让用户控制 优化器如何详见的搜索最佳的查询评估计划。

    一般的方法是 优化器调查更少的执行计划,在编译查询时花费的时间也越少。

    换句话说,优化器跳过一些执行计划, 可能会错过找到一个最佳的方法。

    优化器的行为 使用两个系统变量:

    optimizer_prune_level 变量 告诉优化器来跳过某些几乎基于每个表访问记录的评估。

    我们的实验表明 这种有根据的推测可以很少错过最优计划,

    并可能大大减少查询编译时间。 这是为什么 选项默认是optimizer_prune_level=1

    然而, 如果你相信优化器错过了更好的执行计划,该选项可以关闭

  • 相关阅读:
    互联网协议入门(一)(转)
    程序员的自我修养——操作系统篇(转)
    程序员的自我修养(2)——计算机网络(转)
    里氏替换原则
    Windows Phone 自学笔记 : ApplicationBar
    如何写好代码
    C# 通过操作注册表控制系统 (更新)
    优秀PPT 设计的十大秘诀
    设计模式学习--面向对象的5条设计原则
    SOLID (面向对象设计) From 维基百科
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13351245.html
Copyright © 2011-2022 走看看