mysql高级 --- 查询截取分析

查询截取分析

• 查询优化

  • 永远小表驱动大表，类似嵌套循环Nested loop
    

    • exists
      • select … from table where exists (subquery) 该语法理解为：将主查询的数据，放到子查询中做条件验证，根据验证结果（true或false）来决定主查询的数据结果是否保留
      • 提示
        1. exists（subquery）只返回true或false，因此子查询的select * 也可以是select 1 或select ‘X’ ，官方的说法是实际执行会忽略select清单，因此没有区别
        2. exists 子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比，如果担忧效率问题，可进行实际检验以确定是否有效率问题
        3. exists 子查询往往也可以用条件表达式、其他子查询或者join来代替，何种最优需要具体问题具体解决
           

  • order by 关键字优化

    • ORDER BY子句，尽量使用Index方式排序,避免使用FileSort方式排序
      
      

    • 尽可能在索引列上完成排序操作，遵照索引建的最佳左前缀

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

      • 双路排序

        • MySQL 4.1之前是使用双路排序,字面意思就是两次扫描磁盘，最终得到数据，读取行指针和orderby列，对他们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读取对应的数据输出
        • 从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。

      • 取一批数据，要对磁盘进行了两次扫描，众所周知，I\O是很耗时的，所以在mysql4.1之后，出现了第二种改进的算法，就是单路排序。

      • 单路排序

        • 从磁盘读取查询需要的所有列，按照order by列在buffer对它们进行排序，然后扫描排序后的列表进行输出，它的效率更快一些，避免了第二次读取数据。并且把随机IO变成了顺序IO,但是它会使用更多的空间，因为它把每一行都保存在内存中了。

      • 结论及引申出的问题

        • 由于单路是后出的，总体而言好过双路
        • 但是用单路有问题
          • 在sort_buffer中，方法B比方法A要多占用很多空间，因为方法B是把所有字段都取出, 所以有可能取出的数据的总大小超出了sort_buffer的容量，导致每次只能取sort_buffer容量大小的数据，进行排序（创建tmp文件，多路合并），排完再取取sort_buffer容量大小，再排……从而多次I/O。本来想省一次I/O操作，反而导致了大量的I/O操作，反而得不偿失。

      • 优化策略

        • 增大sort_buffer_size参数的设置
        • 增大max_length_for_sort_data参数的设置
        • 去掉select 后面不需要的字段
        • why
          • 提高Order By的速度
            Order by时select * 是一个大忌只Query需要的字段， 这点非常重要。在这里的影响是：

          1. 当Query的字段大小总和小于max_length_for_sort_data 而且排序字段不是 TEXT|BLOB 类型时，会用改进后的算法——单路排序， 否则用老算法——多路排序。

          2. 两种算法的数据都有可能超出sort_buffer的容量，超出之后，会创建tmp文件进行合并排序，导致多次I/O，但是用单路排序算法的风险会更大一些,所以要提高sort_buffer_size。

          3. 尝试提高 sort_buffer_size
             不管用哪种算法，提高这个参数都会提高效率，当然，要根据系统的能力去提高，因为这个参数是针对每个进程的

          4. 尝试提高 max_length_for_sort_data
             提高这个参数， 会增加用改进算法的概率。但是如果设的太高，数据总容量超出sort_buffer_size的概率就增大，明显症状是高的磁盘I/O活动和低的处理器使用率.

        总结
        
        第二种中，where a = const and b > const order by b , c 不会出现 using filesort b , c 两个衔接上了
        但是：where a = const and b > const order by c 将会出现 using filesort 。因为 b 用了范围索引，断了。而上一个 order by 后的b 用到了索引，所以能衔接上 c

  • group by 关键字优化

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

  • 是什么

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

  • 怎么玩

    • 说明

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

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

        • 默认 — SHOW VARIABLES LIKE ‘%slow_query_log%’;
        • 开启 — set global slow_query_log=1;

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

      • Case

        • 查看当前多少秒算慢
          • SHOW VARIABLES LIKE ‘long_query_time%’;
        • 设置慢的阙值时间
          
          • 为什么设置后看不出变化？
            
            • 需要重新连接或新开一个会话才能看到修改值。 SHOW VARIABLES LIKE ‘long_query_time%’;
            • 或者通过set session long_query_time=1来改变当前session变量;
        • 记录慢SQL并后续分析
          
        • 查询当前系统中有多少条慢查询记录
          

      • 配置版
        【mysqld】下配置：

        slow_query_log=1;
        slow_query_log_file=/var/lib/mysql/atguigu-slow.log
        long_query_time=3;
        log_output=FILE

  • 日志分析工具mysqldumpslow

    • 查看mysqldumpslow的帮助信息
      
    • 工作常用参考

      • 得到返回记录集最多的10个SQL
        mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log

        得到访问次数最多的10个SQL
        mysqldumpslow -s c -t 10 /var/lib/mysql/atguigu-slow.log

        得到按照时间排序的前10条里面含有左连接的查询语句
        mysqldumpslow -s t -t 10 -g “left join” /var/lib/mysql/atguigu-slow.log

        另外建议在使用这些命令时结合 | 和more 使用 ，否则有可能出现爆屏情况
        mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log | more

• 批量数据库脚本

  • 设置参数log_bin_trust_function_creators

    • 创建函数，假如报错：This function has none of DETERMINISTIC…
      由于开启过慢查询日志，因为我们开启了 bin-log, 我们就必须为我们的function指定一个参数。

      show variables like ‘log_bin_trust_function_creators’;

      set global log_bin_trust_function_creators=1;

      这样添加了参数以后，如果mysqld重启，上述参数又会消失，永久方法：

      windows下my.ini[mysqld]加上log_bin_trust_function_creators=1

      linux下 /etc/my.cnf下my.cnf[mysqld]加上log_bin_trust_function_creators=1

    • 产生随机字符串

    • 随机产生部门编号
      

    • 创建存储过程

      • 创建往emp表中插入数据的存储过程
        
      • 创建往dept表中插入数据的存储过程
        

    • 调用存储过程

      • dept
        • DELIMITER ;
          CALL insert_dept(100,10);
      • emp
        • CALL insert_emp10000(100001,500000);
• show profile
  • 是什么：是mysql提供可以用来分析当前会话中语句执行的资源消耗情况。可以用于SQL的调优的测量
  • 默认情况下，参数处于关闭状态，并保存最近15次的运行结果
  • 分析步骤

  1. 是否支持，看看当前的mysql版本是否支持
     

  2. 开启功能，默认是关闭，使用前需要开启
     

  3. 运行SQL

     • 在5.7.5之前，MySQL没有检测到功能依赖项，only_full_group_by在默认情况下是不启用的。
       会报Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column ‘db0629.emp.id’ which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
       解决方法（去掉）：

         * set global sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
         *  set session sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
       

     2. 运行sql语句
        
        

  4. 查看结果，show profiles;
     

  5. 诊断SQL，show profile cpu,block io for query n (n为上一步前面的问题SQL数字号码);

     
     开发中遇到一下几种情况后果非常严重
     ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|
     converting HEAP to MyISAM 查询结果太大，内存都不够用了往磁盘上搬了。
     Creating tmp table 创建临时表
     Copying to tmp table on disk 把内存中临时表复制到磁盘，危险！！！
     locked
     |||||||||||

• 全局查询日志

  • 配置启用

    • 在mysql的my.cnf中，设置如下：
      开启
      general_log=1
      记录日志文件的路径
      general_log_file=/path/logfile
      输出格式
      log_output=FILE

  • 编码启用

    • 命令
      set global general_log=1;

      #全局日志可以存放到日志文件中，也可以存放到Mysql系统表中。存放到日志中性能更好一些，存储到表中
      set global log_output=‘TABLE’;

      此后 ，你所编写的sql语句，将会记录到mysql库里的general_log表，可以用下面的命令查看

      select * from mysql.general_log;

  • 尽量不要在生产环境开启这个功能。