mysql分布式思维（四）-查询优化一

  1.查询优化器模块  

     MySql Query Optimizer    

 mysql数据拿到一个query语句之后都会交给Query Optimizer去解析，并产生 一个最优的执行计划（这个是Optimier认为最优的，不一定是真正最优的）然后按照这个执行计划去执行查询语句。这一部分是最耗时的。有很多第三方为了提高性能绕开mysql的 query optimizer模块。--->HandlerSocket

  2.查询优化的基本思路      

优化更需要优化的query语句

1.  应该优化并发更高的query语句

2. 一个高并发的query语句，如果走错了执行计划，可能会有灾难性的后果

查看执行计划调整query语句     

1. explain  跟查询语句，就能查看执行计划

2. 执行计划中的一些元素  

• Id   查询的序列化

• Select type
        DEPENT SUBQUERY --->说明该查询是子查询中的第一个Select,依赖与外部查询的结果集
       PRIMARY ---->子查询的最外层查询，注意不是主键查询
       simple    ----->除子查询或者UNION之外的其它查询
       subquery

• table 访问数据库的表的名称

• type
       all -->全表扫描
       const--->读常量，且最多只有一条记录匹配。由于是常量只需要读一次
       index --->全索引扫描
       eq_ref --->最多只有一条匹配结果 通过主键和唯一索引来访问的
       range --->索引范围扫描
       possible_keys  --->该查询可以利用到的索引有哪些
       key         --->优化器模块选择用了哪个索引
                      --->有索引不一定就会用到，看执行计划才知道用了哪个。
       key_len  索引长度
       rows 返回的行数
       extra
            using filesort--->说明用了排序算法

• 学会去查看性能损耗(CPU损耗,IO损耗)
     开启 set profiling = 1;
     查看show profiles;
     show profile cpu,block io for query n;

  3.查询的基本原则

 

• 永远用小结果集驱动大结果集

         join查询是，驱动表，一定是条件限定后记录较少的表

         mysql 的join 只有一种算法   Nested loop   通过嵌套循环实现，驱动结果集越大，所需要循环的次数越多，访问被驱动表的次数也越多。降低IO同时降低CPU

• 只取出自己需要的列
    IO降低了
    和排序算法也有关系
• 仅仅使用最有效的过滤条件
     前提是 用a 条件 查询出结果  用b条件查询出结果,a,b都用查询出结果,这三次结果都一样
     到底是用a条件还是b条件，还是两个条件都限定
     只能看执行计划
• 尽量避免复杂的join和子查询
• 尽量在索引列上完成排序和查询
      在索引列上排序  --->索引列上是排好序的，不需要启动额外的排序的算法降低了CPU的损耗
      在索引列上查询---->降低了IO的损耗
      创建了索引，优化器模块不一定就会用。