二、Mysql性能指标及问题分析和定位

1、我们在监控图表中关注的性能指标大概有这么几个CPU、内存、连接数、io读写时间、io操作时间、慢查询、系统平均负载以及memoryOver

上图就是Mysql数据库的缓存区展示了最大缓存以及已使用缓存等数据

3、性能分析

一般在产生Mysql瓶颈的时候往往伴随着的是CPU使用率急速上升需要top看一下是哪个线程占据了大量的CPU资源如果发现Mysql进程占用较高那么基本可以判断是Mysql数据库出现了问题。

对于数据库的操作基本上就是大量的查询会导致数据库出现性能问题。

对有问题的场景使用Jmeter模拟场景进行并发并观察Grafana的图表。

Mysql的几个问题基本上就是1、缓存区较小大量查询导致了缓存区溢出使用io进行读写众所周知io的读写速度远远比内存读写速度要慢得多。

2、sql语句问题导致mysql数据库出现瓶颈的查询语句类型很多最后会给大家列举一些。

那么怎么定位到这些问题呢

Over这个图表如果发现占用基本占满所分配给Mysql数据库缓存区的内存然后IO读写时间非常长读写频率非常高那基本上是可以判断是缓存区较小导致的问题。

这个问题已经很少出现了

log_outputfile,table

在Grafana图表中如果看到慢查询的时间超过1s时基本判断为存在慢查询。

登入数据库运行命令

运行完这条命令后可以查看到所有超过1s的查询语句这个时候复制这条语句到查询输入框中选中右键点击解释。

type列连接类型。

一个好的sql语句至少要达到range级别。

杜绝出现all级别

key列使用到的索引名。

如果没有选择索引值是NULL。

可以采取强制索引方式

key_len列索引长度

MySQL对于IN做了相应的优化即将IN中的常量全部存储在一个数组里面而且这个数组是排好序的。

但是如果数值较多产生的消耗也是比较大的。

再例如select

from

*增加很多不必要的消耗cpu、io、内存、网络带宽增加了使用覆盖索引的可能性当表结构发生改变时前断也需要更新。

所以要求直接在select后面接上字段名。

五、如果排序字段没有用到索引就尽量少排序

or两边的字段中如果有一个不是索引字段而其他条件也不是索引字段会造成该查询不走索引的情况。

很多时候使用

union

或者是union(必要的时候)的方式来代替“or”会得到更好的效果

七、区分in和exists

区分in和exists主要是造成了驱动顺序的改变这是性能变化的关键如果是exists那么以外层表为驱动表先被访问如果是IN那么先执行子查询。

所以IN适合于外表大而内表小的情况EXISTS适合于外表小而内表大的情况。

关于not

在一些用户选择页面中可能一些用户选择的时间范围过大造成查询缓慢。

主要的原因是扫描行数过多。

这个时候可以通过程序分段进行查询循环遍历将结果合并处理进行展示

九、避免在

“%name%”这种查询会导致索引失效而进行全表扫描。

但是可以使用LIKE

十一、注意范围查询语句

对于联合索引来说如果存在范围查询比如between,,等条件时会造成后面的索引字段失效。

type

systemconsteq_refreffulltextref_or_nullunique_subqueryindex_subqueryrangeindex_mergeindexALL除了ALL之外其他的type都可以使用到索引除了index_merge之外其他的type只可以用到一个索引。

所以如果通过执行计划发现某张表的查询语句的type显示为ALL那就要考虑添加索引或者更换查询方式使用索引进行查询。

possible_keys

可能使用的索引注意不一定会使用。

查询涉及到的字段上若存在索引则该索引将被列出来。

当该列为

key

显示MySQL在查询中实际使用的索引若没有使用索引显示为NULL。

TIPS:查询中若使用了覆盖索引(覆盖索引索引的数据覆盖了需要查询的所有数据)则该索引仅出现在key列表中

一些SQL优化建议

9、尽量使用数字型字段若只含数值信息的字段尽量不要设计为字符型这会降低查询和连接的性能并会增加存储开销。

select

11、并不是所有索引对查询都有效SQL是根据表中数据来进行查询优化的当索引列有大量数据重复时SQL查询可能不会去利用索引

最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走

这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你