容易引起雪崩的两个处理

我就是我 2022-09-07 09:43 146阅读 0赞

**背景**

先介绍标题《容易引起雪崩的两个处理》的第一个处理：慢查询。

上周在测试环境遇到一个慢查询问题，虽然是测试环境，但是现象还是很让人担忧的：“在大量执行update操作”“已经执行1个多小时”“负载200多，基本上库都卡死了”。把库都要搞挂了，细思极恐啊。于是，这个事件处理的优先级即刻被升级为S级别，我们进行了点线面的梳理和分析。

**点**

**现象分析**

首先针对此问题做一个分析。

慢查询的原因简单可以这么理解：公司创立之初写的代码，当时上线工期紧，做的比较糙(声明：不代表公司水平)。后台有个人工查询操作，这个操作要查询下游，下游是异步返回结果。所以是通过异步转同步实现的，使用了一张表，每次操作将历史记录标识位全部改成“已过期”，再将新结果插入到数据表中。“在大量执行update操作”指的就是批量更新标识位的操作。大概一次操作要更新几十万条，然后插入几条。一次更新要执行几十秒。

**问题解决**

当时同事提出要加索引解决，我第一个反应：最主要的字段只有两个值：“已过期”、“未过期”。对这种字段加索引是不是没什么用？结果实际测试结果是：不加这条索引十几秒执行完的查询和更新操作，加了索引只要几毫秒。

**原理分析**

这里主要分析三个问题。

**1>为什么这条索引如此管用？**

先说说为什么我第一反应觉得不管用，看看某乎上的神回复：

![0d7cdc6607602559163402b3e4f9f2e4.png][]

![8a9a3d330e7ad77a14e5299cd12e6569.png][]

先说为什么能提高查询速度。

举个例子，假设表中有一千万条记录，状态字段有0和1两个值。某个状态为0的记录总数大概会有100条，那么你想查询状态为0的记录时，有没有索引影响非常大，而查询状态为1的记录，则索引基本无用。如果两种状态的记录数相差无几的话，索引也基本无用。

所有的关于索引的文章，建议你不要为这种字段建索引的依据，都是以值分布是均匀为前提的。但如果值分布不均匀的时候，这个建议就不一定是正确的了。当我们需要查询的记录恰好是分布较少的记录的时候，值分布越是不均匀，索引就越有价值！

那为什么能提高更新速度呢？

对于update/insert/delete的每次执行，字段的索引都必须重新计算更新。听起来很慢，但是更新操作实际上是先select再update的过程，这里因为“未过期”数据条数很少，所以select效率高，然后更新是按照id进行更新，所以很快。

**2>为什么慢查询会导致库卡死？**

一般慢查询，特别是这样将历史记录标识位全部改成“已过期”的，必然会引起锁表。这个表的相关操作会受到影响是可以理解的，但是为什么会影响到整个数据库呢?这就涉及一个最基本的问题：资源竞争。慢查询和慢请求一个道理，长时间占用连接不释放、连接数是有限的，其他后到的请求要排队。

这个问题在生产环境相对好些，因为生产环境一般都会用物理机，而且数据盘至少是SSD的。测试环境资源差很多，所以问题会更明显。

**3>负载200多是什么概念？**

系统平均负载(load averages)是对当前CPU工作量的度量，被定义为特定时间间隔内运行队列中的平均线程数。可以通过top, htop, uptime这些命令找到它们.

关于负载的含义，网上最广泛的示例，是通过桥梁的通过率来解释的。讲的真心好，所以直接「借鉴」过来，需要看原文的直接从参考引用处自行穿越。注意这里的比喻是基于单核CPU的。

> 系统负荷为0，意味着大桥上一辆车也没有 
> 
> 系统负荷为0.5，意味着大桥一半的路段有车
> 
> 系统负荷为1.0，意味着大桥的所有路段都有车，但任然可以顺次通行 
> 
> 系统负荷为1.7，除了桥满之外，在桥的入口处还有70%的车辆在等待

系统负荷为200，除了桥满之外，在桥的入口处还有19900%的车辆在等待！不卡死才怪！

**线**

sql问题影响巨大，所以我们针对所有的数据表进行了梳理，排查隐患。

**面**

还需要梳理所有可能引起稳定性隐患的问题。这里就要引出标题《容易引起雪崩的两个处理》的第二个处理了：递归。

递归如果深度控制不好，会产生栈溢出，也就是StackOverflowError。溢出而使得有用的存储单元被改写，往往会引发不可预料的后果。

怎么改呢？要解决这个问题之前刷的leetcode技能就排上用场了。把递归算法转化为非递归算法有如下三种基本方法  
1、对于尾递归和单向递归的算法，可以用循环结构的算法替代  
2、自己用堆栈模拟运行时栈，分析只保存必须保存的信息（因而可小幅提高时间效率），从而用非递归算法替代递归算法。  
3、利用堆栈保存参数，由于堆栈的后进先出特性吻合递归算法的执行过程，因而可以用非递归算法替代递

**后记**

89年有个电影版的《红楼梦》，演员阵容豪华让人咋舌。赵丽蓉演的刘姥姥、刘晓庆演的王熙凤、傅艺伟演的薛宝钗……。

很小就觉得经典电视剧版的《红楼梦》里薛宝钗优雅端庄，颇有大家闺秀之风。看到了电影版《红楼梦》，特别是有个名场面：宝玉管宝姐姐要她随身挂在脖子上的金锁来看：电视剧版的宝姐姐金锁是挂在贴身内层的，当时宝姐姐是这样的：宝姐姐脸微红，转过身去解下金锁，又缓缓转过来身来，微微笑着给了宝玉。电影版的宝姐姐也是金锁是挂在贴身内层的，宝姐姐听宝玉问他要，她不假思索、干脆利落的解下来给了宝玉。我看到这里，心里的表情是这样的：

![df24bba75f3539bfdcda06bd00709684.png][]

这是哪里来的英姿飒爽的女侠走错了片场？

而在实际工作，我也经常会遇到类似的反差。咱们的每个软件设计和代码，周围的人，后来的人内心都自有评价。愿他们看到的是最好的我们。

**推荐阅读**

## [编写代码的「八荣八耻」(上篇)][Link 1] ##

## [线上问题排查的四类方法][Link 2] ##

## [提高用户体验的三种技术][Link 3] ##

## [近期做的稳定性建设总结][Link 4] ##

[0d7cdc6607602559163402b3e4f9f2e4.png]: /images/20220829/8064c306cb5747f187088c368568a214.png
[8a9a3d330e7ad77a14e5299cd12e6569.png]: /images/20220829/6813a045dce2473eae4634c67d048bf5.png
[df24bba75f3539bfdcda06bd00709684.png]: /images/20220829/0ff6346a18574c04a34343654e1b15d9.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzUzNjAxODg4MQ%3D%3D&chksm=fafde93fcd8a6029a0dc8f47c9f8aa3ede129f38f35da4783c52ba573416a8e101720d7a90de&idx=1&mid=2247484305&scene=21&sn=05f1b974ca26aac83fd5aa1497d741a1#wechat_redirect
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzUzNjAxODg4MQ%3D%3D&chksm=fafdef67cd8a6671acc7735a42619f41970ea1888fb6fc3f4617307b378dd632f3e8407772ad&idx=1&mid=2247484873&scene=21&sn=96cd0c3d3ccb0b0414d871080b9b8350#wechat_redirect
[Link 3]: http://mp.weixin.qq.com/s?__biz=MzUzNjAxODg4MQ%3D%3D&chksm=fafdec65cd8a6573509b9bb25018827ae4cd1c00e44c9e5ea1c7c54ab6246d4ec023de51e072&idx=1&mid=2247485131&scene=21&sn=44e4255d78e53a0df58066c25d6f4dc4#wechat_redirect
[Link 4]: http://mp.weixin.qq.com/s?__biz=MzUzNjAxODg4MQ%3D%3D&chksm=fafde38fcd8a6a99b1c79a1b6bfd7d29cb925be129c2ad2608f28b7e93fb414384c5838568bd&idx=1&mid=2247485729&scene=21&sn=325d273617410e48e3e8c1d8a103421c#wechat_redirect