一、查询优化

1. 小表驱动大表（即小的数据集驱动大的数据集
   原因：如下两个for循环，执行结果是一样的，但是如果放到mysql中，第一种执行，先对数据库建立5次连接，一次连接查询1000条数据，但是第二种在数据库中要建立1000次连接，一次连接才查5条数据，而数据库连接建立释放是比较耗性能的，所以小表驱动大表的来源就在此。

//第一种情况：
for(int i=0 ;i<5 ;i++){ 
    for(int j=0;j<1000;j++){
    }
}
//第二种情况：
for(int i=0 ;i<1000 ;i++){ 
    for(int j=0;j<5;j++){
    }
}

2. in 和 exists查询，如何进行选择
   假如有两个表，A表和B表，其中A表的数据比B表多，那么如果进行子查询
   select * from A where id in (select id from B)，相当于嵌套循环中的先查B，再查A，这就属于小表驱动大表。
   假如必须要查A表中的所有数据，但是A表的数据比B表少，B表的数据比较多，那么要使用exists，而不能是用in，如下：
   select * from A where exists(select 1 from B where B.id = A.id) 此查询是将主查询的数据放到子查询中做条件验证，根据验证结果true 或 false 来决定主查询的数据是否得以保留，此种情况也是属于小表驱动大表；
   注意：A表和B表的id都要创建索引
   提示：
   1. exists(子查询) 只返回true 或者false，因此子查询中的select * 也可以是select 1或者任何常量，官方的解释是，执行时会忽略掉select清单，因此写什么都没有区别。
   2. exists往往可以用条件表达式或者其他子查询或者join来代替，那种最优需要具体问题具体分析
      总结：当子查询的数据多于主查询时用exists优于in，当子查询的数据少于主查询时，用in优于exists。
3. order by 关键字优化
   • MySQL支持两种方式的排序：using index和using filesort
     index效率高，指MySQL扫描索引本身完成排序。filesort效率低，使用了文件外排序。尽量使用index方式排序，避免使用filesort方式排序。
   • 使用index方式排序，需要满足以下两种情况：
     • order by语句使用索引最左前列(注意：select的列要与索引列相同)
     • 使用where字句和order by字句条件列组合，满足索引最前列
       例如：创建一个符合索引，test_code 和 gen_code。

使用索引.png

filesort.png

index.png

索引失效.png

image.png

如果不在索引列上，实在用到了filesort，那么MySQL就要启动双路排序和单路排序算法：

• 双路排序：两次扫描磁盘最终得到数据，读取行指针和order by列，对他们进行排序，然后扫描已排序好的列表按照列表中的值，重新从列表中读取对应的数据输出，这是MySQL4.1之前使用的，两次读取磁盘io，非常耗性能

• 单路排序：MySQL4.1之后出现的，从磁盘读取查询需要的所有列，按照order by 列在缓冲区对他们进行排序，然后扫描排序后的列表进行输出，效率更快，避免了二次读取数据，并且把随机io变成了顺序io，但是会使用更多的空间，因为每一行都在内存中保存着。
  注意：单路排序是比双路排序效率高，但是有前提，内存足够大，因为单路排序是把所有的字段都取出来，所有有可能取出的数据大小超出了sort_buffer的容量，导致每次只能取sort_buffer容量大小的数据，进行排序，排完再取sort_buffer容量的大小...反而导致多次读取磁盘io 。

  解决方案：
  1.order by 时select * 是一个大忌，只select 需要的字段，而不要用*
      1.1 当Query的字段大小总和小于max_length_for_sort_data 而且排序字段不是text|bolb类型，
           会用改进后的算法-单路排序，否则会用老算法-双路排序
      1.2 两种算法的数据都有可能超出sort_buffer的容量，超出之后，会创建temp文件进行合并排序，
           导致多次I/O，使用单路排序算法的风险会大一些，所以要提高sort_buffer_size
  2. 提高sort_buffer_size，不管用哪种算法，提高这个参数，都会提高效率，当然要根据系统的能力去提高，
     因为这个参数是针对每个进程的
  3.提高max_length_for_sort_data，会增加用改进算法的概率，但是如果设置太高，数据总量超过
    sort_buffer_size的概率就会增大，明显症状是，高的磁盘I/O活动和低的cup使用率。
  

4. group by 关键字优化
   • group by 是先排序后分组，用到索引跟order by 一样，遵从索引最佳左前缀原则
   • 当无法使用索引列时，要加大sort_buffer_size和max_length_for_sort_data的值
   • where高于having，能写到where限定条件里的，就不要去having中限定。

二、慢查询日志

1. 慢查询日志解释：
   • 慢查询日志是MySQL提供的一种日志记录，它用来记录MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的sql，则会被记录到慢查询日志中
   • long_query_time的默认值是10，意思是运行10秒以上的语句。
   • 默认情况下，MySQL没有开启慢查询日志，需要手工设置这个参数，如果不是调优需要的话，尽量不要开启，因为开启会影响MySQL的性能，慢查询日志支持将日志写到文件
2. 开启
   • 查看是否开启show variables like '%slow_query_log%',如果slow_query_log=off，那么就是关闭的，
   • 开启慢查询 set global slow_query_log=1,使用此语句以后，只对当前数据库生效，如果MySQL重启则会失效，如果要永久生效，那么需要修改my.cnf文件，在[mysqld]增加或修改参数slow_query_log=1和slow_query_log_file=你要的地址，然后重启服务器，不建议长期开启
   • 如果没有设置慢查询日志文件存放位置，即slow_query_log_file是空的，那么系统会默认给一个缺省的文件host-name-slow.log
   • 命令show variables like '%long_query_time%',此命令可以查看慢查询日志时间，可以在命令行里面修改，也可以在my.cnf中修改。SET GLOBAL long_query_time=1,设置为1秒，修改以后可能没看到修改，需要先断开连接，重新连接才能看到效果。
   • 命令show global status like '%Slow_queries%'，可以查看有多少条慢sql
   • 日志分析工具mysqldumpslow，执行命令mysqldumpslow --help可以查看帮助信息，以下是每个命令的解释：
     • -s：是表示按照何种方式排序；
     • c：访问次数
     • l：锁时间
     • r：返回记录
     • t：查询时间
     • al：平均锁定时间
     • ar：平均返回记录数
     • at：平均查询时间
     • -t：即为返回多少条数据
     • -g：后面可以搭配正在表达式，大小写不敏感
       • 例子1：得到返回记录集最多的10个sql mysqldumpslow -s r -t 10 /var/lib/mysql/mysql-slow.log;
       • 得到访问次数最多的10个sql mysqldumpslow -s c -t 10 /var/lib/mysql/mysql-slow.log;
       • 得到按照时间排序的前10条里面含有左连接的查询语句 mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/mysql-slow.log;
       • 结合 | more可以防止爆屏，mysqldumpslow -s r -t 10 /var/lib/mysql/mysql-slow.log | more;