mysql update语句很慢_缓慢的update语句性能分析

本文描述了一次由于特定`UPDATE`语句导致DB time升高至近1000%的事件。分析了AWR报告,发现主要等待事件为`db file sequential read`。尽管执行计划显示使用了唯一性索引扫描,但SQL执行统计显示出异常的Buffer Gets和Disk Reads。经过磁盘检查排除硬件问题后,怀疑是绑定变量数据类型引起的问题,但未找到确切原因。最后,通过ADDM报告确认了I/O子系统的性能瓶颈。
摘要由CSDN通过智能技术生成

最近处理一个问题的时候,先是收到DB time升高的报警,然后查看DB time的情况发现,已经有近1000%的负载了。

最近处理一个问题的时候,先是收到DB time升高的报警,然后查看DB time的情况发现,已经有近1000%的负载了。

2390863bc4a73fe7c27f04c5100bb73e.png

带着好奇心想看看到底是什么样的一个语句导致如此的情况。

先抓取了一个awr报告,因为问题发生的时间段比较集中而且时间持续有几个小时,所以抓取了一个小时的快照。

得到的awr部分内容如下:

Cache Sizes

BeginEnd

Buffer Cache:

39,472M

39,472M

Std Block Size:

8K

Shared Pool Size:

1,440M

1,440M

Log Buffer:

14,256K

从下面的部分可以看出数据库其实内部的活动并不多,redo生成量不高,tps也不高。

Load Profile

Per SecondPer Transaction

Redo size:

154,276.41

24,024.13

Logical reads:

4,864.90

757.57

Block changes:<

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值