zoukankan      html  css  js  c++  java
  • MySQL HINT:Straight_JOIN

         来自生产环境的朋友、可能都会碰到:
         
         原本运行良好的查询语句,过了一段时间后,可能会突然变得很糟糕
         一个很大可能的原因就是数据分布情况发生了变化
         从而导致MySQL优化器对驱动表的选择发生了变化,进而出现索引失效的情况
         所以、闲着蛋疼喝咖啡的时候、应该多收集两下表的统计信息
         
         
         这个时候、Straight_JOIN 闪亮登场
         
         
         MySQL 只支持 Nested Loop Join、关于这个Nested JOIN的详细用法请参阅偶之前blog:点击打开链接
         和Oracle对比下、不然得知、Straight_JOIN相当于Oracle里面的:USE_NL、所以、原理和适用上大概都是相同的、
         不过、对于驱动表的选择、MySQL 优化器可能没有Oracle那般智能、MySQL采用简单粗暴的方法:
         哪个表的结果集小,就以哪个表为驱动表
         
         
         
         
    偶赶脚有2 种原因可令你选择 Straight_JOIN 
         
         ① MySQL 优化器不给力、错误选择驱动表
         ② Nested Loop Join 的适用场景:
            ==>一般用在连接的表中有索引,并且索引选择性较好(也就是Selectivity接近1)的时候
            ==>也就是驱动表的记录集比较小(<10000)而且inner表需要有有效的访问方法(Index)
            
            
            
            
          一般的优化操作:
         
         
         ① show full processlist; <===查找TOP-SQL 
         ② explain + TOP-SQL ; <===查询SQL 执行计划
         
         注意:在EXPLAIN结果中,第一行出现的表就是驱动表
         
         
         
         
          一个经典优化例子:
         
         当explian输出结果中含:「Using filesort」,甚至「Using temporary」
         我们就该擦亮双眼、像打了鸡血一样、保持时刻优化的姿态

         此刻的优化就容易多了、尽可能保证排序字段在驱动表中

     

     

    By David Lin

    2013-06-23

    Good Luck

  • 相关阅读:
    为《理解C#中的System.In32和int:并非鸡和鸡蛋 》做个续
    Windows C++代码heap分析详解
    Windows 内存分析之路 How to use Resource Monitor
    给C++初学者的50个忠告(好文转载)
    The 32bit generalpurpose registers EAX, EBX, ECX, EDX, ESI, EDI, EBP, and ESP
    Exceptional C++ 精华代码—实现异常安全的Stack
    Windows开发的内功和招式
    Windows代码heap内存分析实战
    十分钟让你对C++ Traits大彻大悟
    使用Windows API PostThreadMessage进行线程间消息通信
  • 原文地址:https://www.cnblogs.com/dyllove98/p/3151150.html
Copyright © 2011-2022 走看看