MySQL查询慢性能分析

# 可能的原因

## 1. 未使用索引

查看是否建立了索引
```sql
mysql> show create table APP_TASK ;
  PRIMARY KEY (`ID`),
  KEY `idx_task_type` (`TASK_TYPE`), -- 表示有该字段的查询索引
```

如果未使用索引，则考虑是否需要建立索引加速

## 2. 索引不符合预期

使用`explain` + `查询语句` 打印查询语句的情况分析:
```SQL
-- 示例
mysql> explain select count(E.Status) from APP_TASK E WHERE E.TASK_TYPE = '6';
```
![](/media/202307/2023-07-28_151025_2297810.5394318566840691.png)

上面的语句中：

- `type`的值的定义如下：
	all：代表全表扫描
	ref：代表使用非唯一性索引或者唯一索引的前缀扫描
	index：代表全索引扫描
	range：索引范围扫描
	eq_ref：类似ref, 使用索引是唯一索引
	null：直接返回结果,无需访问表和索引

- `possible_keys`是指可能用得到的索引，这里可能使用到的索引是为idx_task_type建的普通索引

- `key`是指实际使用的索引，值为NULL表示不走索引，全表扫描。

- `rows` 预估这个查询语句需要查的行数的，不一定完全准确

## 3. 连接数较少

正常情况下，客户端与server层如果只有一条连接，在执行sql查询之后，只能阻塞等待结果返回，如果有大量查询同时并发请求，后面的请求都需要等待前面的请求执行完成后，才能开始执行。

![](/media/202307/2023-07-28_153016_5420600.17675770110547862.png)

设置方法：
```SQL
mysql> set global max_connections= 1500;
Query OK, 0 rows affected (0.00 sec)
```

4. 缓冲命中率过小

数据库查询流程中，在sql进入innodb后，会有一层内存buffer pool，用于将磁盘数据页加载到内存页中，如果查询到buffer pool中存在结果，就可以直接返回，否则需访问磁盘IO，降低查询速度。

理论上，buffer pool 越大，能放的数据页就越多，相应的，sql查询时就更可能命中buffer pool，查询速度更快。

可通过命令查询buffer pool的大小，单位是Byte。

查询buffer pool大小

设置buffer pool大小

```SQL
mysql> set global innodb_buffer_pool_size = 536870912;
Query OK, 0 rows affected (0.01 sec)
```

查看缓存命中率

通过 show status like 'Innodb_buffer_pool_%';可以看到跟buffer pool有关的一些信息。

Innodb_buffer_pool_read_requests表示读请求的次数。

Innodb_buffer_pool_reads 表示从物理磁盘中读取数据的请求次数。

所以buffer pool的命中率就可以这样得到：

复制
buffer pool 命中率 = 1 - (Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests) * 100%
1.
比如我上面截图里的就是，1 - (405/2278354) = 99.98%。可以说命中率非常高了。

一般情况下buffer pool命中率都在99%以上，如果低于这个值，才需要考虑加大innodb buffer pool的大小。