12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
ADADADADAD
mysql数据库 时间:2024-11-26 22:15:19
作者:文/会员上传
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
12-09
#####msyq 版本:mysql 5.5操作系统:CentOS 52019-06-05#####最近监控告警,CPU使用率间歇性上升至 95% 以上,通过 show processlist; 查看,发现存在 60多个活动session 在执行同一
以下为本文的正文内容,内容仅供参考!本站为公益性网站,复制本文以及下载DOC文档全部免费。
#####
msyq 版本:mysql 5.5
操作系统:CentOS 5
2019-06-05
#####
最近监控告警,CPU使用率间歇性上升至 95% 以上,通过 show processlist; 查看,发现存在 60多个活动session 在执行同一个SQL: select count(*) from xxxxx(这里没有where 子句)。
看到这里,大家可能会觉得,哦,问题找到了,因为这SQL 导致CPU使用率上升。这样的判断是否有点武断呢?
CPU 使用率上升是因 还是果呢? 或者说数据库中同时存在 多个 session 执行同一个SQL ,这是因为 CPU 使用率上升导致的还 是因为这个SQL 导致CPU使用率上升的呢?
后来研发组在应用程序上缓存了 该SQL 的结果集,问题解决。这说明确实是该SQL 导致CPU使用率上升的,但我有个凝问,count 类型的操作,没有排序的情况下,不是该占用更多的是I/O 资源吗?
带着这个凝问,我百度了一下,没有找到答案,然后我作了一个测试:在 select count(*) from xxxx 前后通过 show status 查看 Innodb_buffer_pool_read_requests 和 Innodb_buffer_pool_reads 的值,事实证明,该SQL 请求磁盘IO的次数很少,说明大量的数据检索是走的内存。这正好解释 count(*) 类型的查询会导致CPU上升的原因。
11-20
11-19
11-20
11-20
11-20
11-19
11-20
11-20
11-19
11-20
11-19
11-19
11-19
11-19
11-19
11-19