软件性能瓶颈问题之数据库性能问题定位

最新推荐文章于 2024-05-11 11:33:15 发布

测试界的咸鱼仔

最新推荐文章于 2024-05-11 11:33:15 发布

阅读量395

点赞数

文章标签：数据库 mysql jmeter 测试性能

本文链接：https://blog.csdn.net/cae_520_ww/article/details/133774302

版权

前言：数据库的性能瓶颈包括：数据库索引，锁，表空间，慢sql，数据量

一、性能问题

1.1 缺乏索引：

索引本质上是一种数据结构，允许数据库快速查找特定的数据

1.2 查询效率低：

使用通配符，例如select * from student where student_name =“%乐乐%”’，在搜索词之前和之后使用“%”通配符会使此查询非常慢，尤其是在会话表很大的情况下。数据库需要扫描会话表中的每一行，并针对每一行评估 LIKE 运算符，这可能非常耗时；转换为索引查询，如select * from student where student_ID= 200,如果给student_ID添加索引，查询比上一个快得多

最好避免在 SQL 查询中使用通配符（如“%”），因为它们可能会导致性能缓慢且效率低下。相反，请尝试使用利用索引来提高查询性能的目标查询

1.3 数据类型不正确：

不合适的数据类型导致性能不加和存储空间浪费，如：对应为整数的字段使用 varchar 数据类型可能会导致性能问题。

在设计数据字段的时候要了解数据用途和扩展，如果要设计一个字段来存储名称，则应考虑名称的长度以及它们是否可以包含特殊字符。同样，如果要设计一个字段来存储电话号码，则应考虑是否将存储国际号码

1.4 连接数不够：

1、数据库配置不合理, 默认为100

命令修改: set golbal max_connections = 1024;
配置修改: /etc/my.cnf max_connections = 1024;
重启: service mysqld restart

2、慢查询导致IO阻塞, 连接长时间得不到释放

慢查询不是及时可以看到的, 一般当一个sql执行完才能判断是否为慢查询

3、代码缺陷sql执行完, 连接未释放

1.5、缓存命中率低

查询缓存是否开启: show variables likes “%query_cache%”;

开启缓存: set session query_cache_type = ON;

二、性能问题定位

1、explain分析

表的读取顺序
表的读取操作的操作类型
哪些索引可以使用
实际命中索引
表之间的引用
每张有多少行被检索

1、具体操作：在查询语句前加上explain，得到如下字段返回值

字段含义解读：

id: 语句的执行顺序标识, 优先级越高, 越先执行
select_type: 查询类型
1. simple: 简单类型
2. primary: 若包含任何复杂的子部分, 最外层查询被标记为primary
3. union: 连表查询时, union之后的select, 则被标记为union第一个select为primary
table：访问列表名称
type：访问类型，有无使用索引

1、system: const的一个特例, 表中只有一条记录时发生
2、const: where条件被转换成常量, 只读取一次数据就能获取结果, 最多有一条记录匹配(主键, 唯一索引)
3、eq_ref: 走索引, 返回单行的数据.(连表查询时出现, 主键或唯一索引)
4、ref: 走索引, 返回的数据可以是多行, 通常使用等于时发生(普通索引)
5、range: 用了索引, 进行范围扫描, 常用于between, <, >, in等操作
6、index: 全索引扫描, 最简单的例子, select id from table
7、all: 全表扫描(重点关注)

5、possible_keys：可以利用索引，无索引责显示null

6、key：从possible_keys中所选择使用的索引

7、rows：结果条数

8、extra：查询方式

1. using index：只用索引, 可以避免访问表
2. using where：使用到where来过滤数据, 不是所有的where都要显示using where(访问了索引, 显示为using index)
3. nusing tmporary：用到临时表
4. nusing filesort：用到额外的排序