五花八门客户问题(BUG) - 数据库索引损坏

客户遇到index周期性损坏的问题,严重影响数据查询。尝试通过触发器实时检查和诊断构建追查原因,但均带来性能问题。最终在实验室通过模拟客户更新操作发现,index建立在频繁更新字段上是问题根源。此过程还衍生出记录和回放客户更新的解决方案。

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

问题

曾经有个客户问题,让我们开发不知所措了很久。简单点说就是客户的index周期性的损坏,即使全部重建后经历大约1~2周数据update后也会坏掉。导致的直接结果:select出来的数据不对。问题很严重。

直接看损坏的index文件看不出什么蛛丝马迹,因为它已经面目全非。所以我们一直想拿到第一条导致update出错的insert、update,或者delete.

开始探索

沿着上面提到的思路,给力的support写了一个trigger,只要每次更新(insert、update,或者delete)数据,trigger就调用index检查程序检查index文件是否有问题。客户也比较配合的部署上了,但是只过了几天就禁用掉了,因为每次检查index文件都耗时巨大,直接拖慢了客户business performance。

另寻他路

除了trigger,我们还可以出diagnostic build, 基本就是往怀疑的地方加log,此种办法耗时耗力:先在对应的版本上改代码-> 编译 -> 发给客户 -> 客户部署,重启数据库. 一般来往一次耗时一两周,而且一次都不一定成功。

后来我又想出一个办法:客户发我们问题表,同时我们帮客户记录下客户的所有更新直到select结果不对。我们有继承数据(index没问题的表),在实验室一条条的重复更新客户操作即可。这个办法涉及客户数据,取决于他们在不在乎。好在客户不care这些。

BUG

后来我们真的在实验室重现了,罪魁祸首竟然是index建在最后一个字段大量更新后就会有问题。看来测试不能放过任何一种情况啊,起码得设计三个字段然后所有可以创建index的列的组合都要设计test case。

附加产出

如何记录客户的更新:我们有一个replication功能(本人负责),正常是把更新发给另外一台机器的,但也可以暂时不发而是写入一个log文件,于是我拿到log文件就拿到了客户的更新。

把log文件中的更新写入表:我写了一个replay.py解析log文件中的每一条更新,调用数据库接口写入表中。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

深山老宅

鸡蛋不错的话,要不要激励下母鸡

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值