50个并发持续5 min 请求 ，平均耗时 19s ，问题排查分析
一、jmetter 压测分析
1621497303779.png
二、涉及到服务
- mid-platform-dataset
- mid-platform-audit
三、 相关服务耗时分析
mid-platform-dataset 服务耗时分析
1、存在多表连接查询，且（yl_data_set_db [t2] , yl_data_set_api [t3]） 全表扫描，未命中索引，性能影响很大。
image.png
建议， t2,t3 表字段（data_set_id） 添加普通索引（添加索引时先看数据量，避免因索引添加造成系统卡顿）
加入索引
ALTER TABLE yl_data_set_db ADD INDEX idx_data_set_id (data_set_id);
ALTER TABLE yl_data_set_api ADD INDEX idx_data_set_id (data_set_id);
1.1 、查看添加索引后的执行计划，扫描行数为1 ，
2、PreviewData 请求数据集接口预览数据，
2.1 、查看这个用户的请求大概耗时， 可以看到这个用户的请求线程号为： XNIO-1 task-5
image.png
（日志信息太少，建议之后多加日志） 粗略估计执行s耗时为2s 多，，这个接口耗时有点严重。
（这里优化空间很大，，索引加上能减少扫描耗数据行耗时）
mid-platform-audit 审计日志服务
查询top 审计日志优化
-- 原始sql
EXPLAIN select system_name, count(1) as num
from yl_audit_log
where DATE_FORMAT(operation_time,'%Y-%m-%d') = "2020-09-07"
group by system_name ORDER BY num desc limit 10
-- 创建复合索引
ALTER TABLE yl_audit_log add INDEX idx_mutiplex_1(operation_time,system_name);
-- 优化后sql
EXPLAIN SELECT system_name, COUNT(*) num
FROM ( SELECT operation_time,system_name FROM yl_audit_log WHERE operation_time > "2020-09-07 00:00:00"
AND operation_time <= "2020-09-07 23:59:59") t
GROUP BY
system_name ORDER BY num desc limit 10;
优化对比
-
未优化前， 数据全表扫描，数据从磁盘全量扫描到内存进行分组排序， 临时表内存占用大内存压力可想而知，数据量大造成磁盘IO 压力。
1621568905610.png
- 优化后， 范围扫描，只扫描日期范围的数据。
1621569003795.png
接口响应前后对比
- 优化前
1621583008648.png
1621825533316.png
1621825620443.png
- 优化后
1621830939611.png
1622079275757.png
