当前位置:首页 > 开发技术

一则MySQL优化实例

Neo

发布时间:2019-09-29 04:34 阅读:317 专题:开发技术 原创 | 来源 波波说运维 | 石杉的架构笔记

摘要:原标题: 一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题

最近编辑时间:2019-09-29 04:35

概述

最近接到IDC监控告警说某台服务器cpu过高,下面记录下故障排查的过程,仅供参考,这里主要看思路,细节不重要。

1、观察服务器资源消耗

可以看到服务器表现为cpu问题,内存消耗正常。


一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题





一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题




1.1、查看具体cpu

ps -mp 2289 -o THREAD,tid,time


一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题





一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题




1.2、找到耗时最高的线程TID,并将其线程ID转换为16进制格式:

printf "%x\n" tid


一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题




1.3、打印线程的堆栈信息,thread dump

jstack pid |grep tid -A 30

进一步分析堆栈信息

2、检查数据库线程

这里发现大概有8个线程,而且都是同一条sql


一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题




3、查看sql执行计划

这个单条sql只需要2s就可以跑完,不过看执行计划是走了全表扫描,并没有走索引


一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题





一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题




4、慢查询分析

set global slow_query_log=on;
set global long_query_time=30;
set global log_output='TABLE';
show variables like '%slow%';
select * from mysql.slow_log order by 1;


一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题




以下是因为先开了没有走索引就记录下来,所以可以看到这条sql,但是开了慢查询后并没有超过30s的慢sql.


一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题




5、定时任务?

跟开发确认后是有个定时任务,每次都需要去查每个用户的考勤时间,最后再汇总统计,这个定时任务需要跑一天的时间。

这里问题主要是嵌套循环,外层循环遍历工号(8000),内层循环遍历天数(30天),然后内层循环每次查数据都需要去跟数据库做一次交互,在插入数据到缓存,最后汇总计算到汇总表。

6、优化方案

1、汇总表拆分

常用字段划为一张表,不常用字段划分为另一张表,然后常用字段这些只做汇总计算,不走循环,不常用字段(如婚假、病假等)这些走循环。


一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题




2、优化单条查询

这个建索引,控制在1s内

--大表建索引,驱动表不建索引
create index idx_hwb1 on t_att_dd_attendance_info(user_id,class_id,check_type,plan_check_time)


一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题




3、逻辑优化

这里跟开发提了把逻辑改了,不过开发还没实现,所以就不贴实现代码了。逻辑大致如下:

--目前逻辑
{
 /*外层循环遍历工号*/
 {
 /*内层循环遍历天数*/
 }
}
--优化后的逻辑
{
 /*外层循环遍历天数*/
 {
 /*内层循环遍历工号*/
 }
}

END


本文地址:http://www.java-go.cn/article_639 © 著作权归作者所有

上一篇:配置Nginx防止流量攻击 下一篇:该如何弥补 GitHub 功能缺陷?

发布评论
发送
0条评论

热门文章

最新答疑

推荐导航