（八）查询截取分析

分析流程：
1.观察一定周期，看看生产的慢SQL情况
2.开启慢查询日志，设置阈值，比如超过5秒钟就是慢SQL，并将它抓取出来
3.explain+慢SQL分析
4.show profile
5.进行SQL数据库服务器的参数调优
总结下来就是：
1.慢查询的开启并捕获
2.explain+慢SQL分析
3.show profile查询SQL在MySQL服务器里面的执行细节和生命周期情况
4.SQL数据库服务器的参数调优

1.查询优化

1.1 永远小表驱动大表

1.2 order by关键字的优化

order by子句中，尽量使用Index方式排序，避免使用FileSort方式排序
尽可能的在索引列上完成排序操作，遵照索引键的最佳左前缀原则
建表：

create table tblA{
  age int,
  birth timestamp 
  
}

create index idx_a_ageBirth on tbla(age,birth)

1.3 如果不在索引列上，filesort有两种算法(mysql就要启动双路排序和单路排序)：

• 双路排序：MySQL4.1之前是使用双路排序，字面意思就是两次扫描磁盘，最终得到数据，读取行指针和orderby列，对他们进行排序，然后扫描已经排好的列表。从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。
• 单路排序：从磁盘读取查询需要的所有列，按照orderby列再buffer对它们进行排序，然后扫描排序后的列表进行输出，它的效率更快一些，避免了第二次读取数据。并且把随机IO变成。
• 结论及引申出的问题：
  • 由于单路是后出的，总体而言好过双路
  • 但是用单路有问题(本来想省一次IO操作，反而导致了大量的IO操作，反而得不偿失)

1.4 优化策略

• 增大sort_buffer_size参数的设置
• 增大max_length_for_sort_data参数设置
  提高order by查询速度
  

1.5 group by关键字优化

• groupby实质是先排序后进行分组，遵循索引键的最佳左前缀
• 当无法使用索引列，增大max_length_for_sort_data参数的设置+增大sort_buffer_size参数的设置
• where高于having，能写在where限定的条件就不要去having限定了。

1.6 为排序使用索引总结

2.慢查询日志分析

• MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阙值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。
• 具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10秒以上的语句。
• 由他来查看哪些SQL超出了我们的最大忍耐时间值，比如一条sql执行超过5秒，我们就算慢sql，希望能收集超过5秒的sql，结合之前的explain进行全面分析。

2.1 说明：

默认情况下Mysql数据库没有开启慢查询日志，需要我们手动来设置这个参数。
当然，如果不是调优的需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影像。慢查询日志支持将日志记录写入文件。

2.1 查看是否开启及如何开启

• 默认：SHOW VARIABLES LIKE '%slow_query_log%';
• 开启：set global slow_query_log=1;
• 永久生效
  
  关于慢查询的参数slow_query_log_file,它指定慢查询日志文件的存放路径，系统默认会给一个缺省的文件host_name-show.log(如果没有指定参数slow_query_log_file的话)

2.2 开启了慢查询日志后，什么样的SQL才会记录到慢查询日志里面呢？

• 这个是由参数long_query_time控制，默认情况下long_query_time的值为10秒
• 命令：SHOW VARIABLES LIKE '%long_query_time%'
• 可以使用命令修改，也可以在my.cnf参数里面修改
• 假如运行时间正好等于long_query_time的情况，并不会被记录下来。也就是说，在mysql源码里是判断大于long_query_time,而非大于等于。