性能测试四十一：sql案例之慢sql配置、执行计划和索引
MYSQL 慢查询使用方法
MYSQL慢查询介绍
分析MySQL语句查询性能的问题时候，可以在MySQL记录中查询超过指定时间的语句，我们将超过指定时间的SQL语句查询称为“慢查询”。MYSQL自带的慢查询分析工具mysqldumpslow可对慢查询日志进行分析：主要功能是, 统计sql的执行信息，其中包括 ：
出现次数(Count),
执行最长时间(Time),
累计总耗费时间(Time),
等待锁的时间(Lock),
发送给客户端的行总数(Rows),
扫描的行总数(Rows),
用户以及sql语句本身(抽象了一下格式, 比如 limit 1, 20 用 limit N,N 表示).
案例：慢sql
先确定项目指向的数据库是对的
问题接口：http://localhost:8080/PerfTeach/SlowQuery?cardNO=10001
由于数据库里面是card_no，而代码里面是cardNO，所以要改一下数据库里面的字段名
修改
访问一下：http://localhost:8080/PerfTeach/SlowQuery?cardNO=10001，和数据库里的一样
在jmeter里面造一个10000--20000的随机数函数
监控开起来
运行jmeter，用10个并发，跑600秒
TPS很低
响应时间很长
CPU高
mysql进程占了89.9%的cpu使用率
所以，可以确定是mysql这块有问题，而这种问题一般都是sql写的不好造成的
1、 开启慢SQL的配置
1．1 LIUNX 系统 在mysql配置文件my.cnf中（文件最后）增加
slow_query_log：这是一个布尔型变量，默认为真。没有这变量，数据库不会打印慢查询的日志。
slow_query_log_file=/usr/local/mysql/data/zhoucentos-slow.log：(指定日志文件存放位置（安装mysql的目录），可以为空，系统会给一个缺省的文件hostName-slow.log)
long_query_time=0.1：(记录超过的时间，默认为10s)，与DBA沟通，性能测试分析问题时可以将该值设为0.1即100毫秒，这样分析的粒度更详细。
备选 ：log-queries-not-using-indexes (log下来没有使用索引的query,可以根据情况决定是否开启)。log-long-format (如果设置了，所有没有使用索引的查询也将被记录)
重启mysql
1．2 Windows下配置:
在my.ini的[mysqld]添加如下语句：
log-slow-queries = E:\web\mysql\log\mysqlslowquery.log
long_query_time = 0.1(其他参数如上)
注： 配置完成后，重新mysql服务配置才能生效。
2、 慢查询开启与关闭
2．1 配置完成，连接数据库检查慢查询日志是否开启：
命令如下：mysql> show variables like '%slow_query_log%';
压一下，看看有没有数据写进去，从172，变成了124800，使用-h查看：122K
2．2 如果没有打开，请开启,slow_query_log，以下方法是一次性的，只要重启mysql就会恢复到原样
开启命令：mysql> set @@global.slow_query_log = on;
关闭命令：mysql> set @@global.slow_query_log = off;
2．3 再次检查是否开启成功
mysql> show variables like '%slow_query_log%';
2．4 检查目录中是否生成文件
/mysql目录下是否存在mysql_slow.log
[root@localhost mysql]# ls -l mysql_slow.log
3、 慢查询日志分析
3.1 Linux系统:
使用mysql自带命令mysqldumpslow查看（需在mysql/bin目录下执行，因为mysqldumpslow在bin目录下）
常用命令，通过 ./mysqldumpslow -help查看
-s，是order的排序，主要有 c,t,l,r和ac,at,al,ar，分别是按照query次数，时间，lock的时间和返回的记录数来排序
-a，倒序排列
-t，是top n的意思，即为返回前面多少条的数据
-g，后边可以写一个正则匹配模式，大小写不敏感的
例如：
./mysqldumpslow -s c -t 20 host-slow.log：访问次数最多的20个sql语句
./mysqldumpslow -s r -t 20 host-slow.log：返回记录集最多的20个sql
./mysqldumpslow -t 10 -s t -g “left join” host-slow.log这个是按照时间返回前10条里面含有左连接的sql语句。
./mysqldumpslow -s at -t 50 host-slow.log 显示出耗时最长的50个SQL语句的执行信息（此方法最常用）
总共执行了602次，平均执行390毫秒，和jmeter统计出来的平均响应时间差不多了，所以，时间都耗在执行sql上面了
由于这里数据量不够，所以找了个项目中的图
以Count: 32 Time=0.26s (8s) Lock=0.00s (0s) Rows=10.0 (320), wos_20120719[wos_20120719]@2host 为例：
Count: 32 该SQL总共执行32次
Time = 0.26s (8s) 平均每次执行该SQL耗时0.26秒，总共耗时32（次）*0.26（秒）=8秒。
Lock=0.00s(0s) lock时间0秒
Rows =10.0(320) 每次执行SQL影响数据库表中的10行记录，总共影响 10（行）*32（次）=320行记录
执行计划
在sql语句前加上explain，可以分析这条sql语句的执行情况：explain select * from teacher where cardNO=10000
select_type：
SIMPLE：简单查询
Type列可能的值（以下按效率降序排列）：
Const：表中只有一个匹配行，用到primary key或unique key （性能最好）
Eq_ref：唯一性索引扫描，key的所有部分被连接联接查询使用，且key是unique或primary key
ref：非唯一性索引扫描，或只使用了联合索引的最左前缀
Range：索引范围扫描，在索引列上进行给定范围内的检索，如between，in（1,100）
Index：遍历索引...（类似于在字典上找字）
All：全表扫描（没有用索引，直接从表里面第一条找到最后一条（即使在前面或中间已经找到数据），所以项目中一般禁止使用select*和全表扫描）
所以上面就运行那条简单的sql，确很费cpu，就是因为在进行全表扫描
在工作中，一般有以下3种情况会造成sql效率低：
1.库里面没有加索引
2.加了索引，但是索引加的不合理
3.索引加的合理，但是sql写的不合理
一般，一个表里面，最多加3/4个索引，不能再多，否则就是表设计的不合理
上面那个情况就是应为没有加索引，所以，加个索引看看，
一般加索引，就看where条件的字段，用这些字段来当索引，这条sql就一个字段：cardNO
压一下看看
TPS从刚才的20多变成了300多，提升了15倍左右
响应时间：从刚才的400左右，降到30左右
TOP命令查看，mysql只占了22.2%，一般项目中就应该是tomcat占比最高，应为它要处理业务逻辑
由于压测还在进行中，所以可以把慢查询的日志清空后再看看还有没有慢查询
文件大小都是0了，没有往文件里面写入内容了
3.2 Windows系统:
当你是第一次开启mysql的慢查询，会在你指定的目录下创建这个记录文件，本文就是mysqlslowquery.log，这个文件的内容大致如下(第一次开启MYSQL慢查询的情况下)
E:\web\mysql\bin\mysqld, Version: 5.4.3-beta-community-log (MySQL Community Server (GPL)). started with:
TCP Port: 3306, Named Pipe: (null)
Time Id Command Argument
可以通过如下的命令来查看慢查询的记录数：
mysql> show global status like ‘%slow%’;
+———————+——-+
| Variable_name | Value |
+———————+——-+
| Slow_launch_threads | 0 |
| Slow_queries | 0 |
+———————+——-+
