性能测试中数据库索引和MySQL数据库慢SQL问题的定位和分析【杭州多测师】【杭州多测师_王sir】...

数据库性能问题：

TPS很低、响应时间比较长然后数据库服务器的CPU特别搞接近100%、但是应用服务器的负载比较低

索引：是MySQL数据库中一列或者多列的值进行排序的结构、使用索引可以快速访问数据库中的特定信息、有点像书的目录

分析：

数据库服务器CPU高一般都是SQL执行效率低导致的

1)数据库缺少一些索引

2)索引不生效

3)SQL语句写的不够优化

1、采用10个并发、持续300秒、在Linux服务器用jmeter -n -t test.jmx去压测

2、服务器的CPU空闲99%-100%、TPS达到300/sec左右、但是数据库服务器CPU差不多达到了100%、应用服务器的负载是比较低的

3、通过如下的方法排查MySQL数据库的可能存在的慢SQL ==》性能测试中MySQL数据库慢查询使用方法【杭州多测师】【杭州多测师_王sir】

4、explain SQL语句发现 ==》rows达到20000多次说明需要找2万多次才能查询到结果、然后type也是all说明是使用了性能最差的全表扫描 ==》一般这种全表扫描是最不建议去使用的

5、然后开始给没有加索引的字段加上索引、把其中的一个字段name加上索引、索引的类型可以改为unique这个是唯一索引、字段里面的值是不能重复的、如果需要重复的可以选择索引类型为：normal、但是性能没有unique那么好

6、加完之后发现type从all变成了const、表中只有一个匹配行、从性能最差的类型变成了性能最好的type类型了

7、然后在去Linux服务器执行jmeter脚本进行压测、发现tps能达到20000了、CPU服务器空闲也剩了40%左右 ==》服务器的性能和能支持多少并发关系不大==》衡量服务器的性能只能是通过tps和响应时间来衡量==》性能好

的服务器很少的并发也可以达到很高的tps

8、然后在把索引的类型unique改为normal、type从const变为了ref、tps瞬间变为了17000多、少了3000多的tps

通过Navicat连接上MySQL数据库然后在sql语句前加上explain，可以分析这条sql语句的执行情况
explain select * from student where name = xxx
Type列可能的值
Const：表中只有一个匹配行，用到primary key或unique key ==》性能最好
Eq_ref：唯一性索引扫描，key的所有部分被连接联接查询使用，且key是unique或primary key
ref：非唯一性索引扫描，或只使用了联合索引的最左前缀
Range：索引范围扫描，在索引列上进行给定范围内的检索，如between，in(1,100) Index：遍历索引...
All：全表扫描  ==》性能最差
Prossible key：使用哪个索引能找到行
Keys：sql语句使用的索引
rows：mysql 根据索引选择情况，估算查找数据所需读取的行数