一个简易查询引起的悲剧

探讨了一个历史库服务器在进行表查询时遇到的问题。该服务器包含约20个数据库,14000个连接及50个并发请求。原本运行良好,但在某些表上增加索引后出现问题。经过排查发现,一个被假定为主键的列实际上并非主键,导致查询阻塞。这提示我们,在优化查询和解决问题时,应细致检查表结构。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

             有一个历史库服务器,大约有20左右的数据库,14000左右的连接,50左右的并发,平日表现的挺好的,一日忽然间闹腾起来了,在一些表上加了索引,好转一些,但是仍然报警。

            实际上,每天抓到的BAD TRACE 并不是很多,并且大部分查询条件都很简单,一些查询时间比较长的查询出现的次数也不多,这个事情纠结了几天,终于一日无法在忍受了,和同事一起查看,发现一个简单的查询竟然有阻塞。

           这个查询的条件列是我认为表的主键列,怎么会有阻塞呢?查看表结构发现,这个表没有主键,悲剧啊。我一直认为这样的查询条件不会出现什么问题,但是问题出现在表上没主键。纠结。

           也许这个问题出现了好久了,之前CPU 没有达到报警的阈值,所以也没去查原因,查原因的时候又先入为主的认为简易查询肯定没问题。也许MISSINGINDEX,以及数据库阻塞都可以给出答案,重要的是 要有发现问题的系统思想,要细心去发现。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值