产品中心
背景
最近线上的一个工单分析服务一直不大稳定，监控平台时不时发出数据库操作超时的告警。
运维兄弟沟通后，发现在每天凌晨1点都会出现若干次的业务操作失败，而数据库监控上并没有发现明显的异常。
在该分析服务的日志中发现了某个数据库操作产生了 SocketTimeoutException。
开发同学一开始希望通过调整 MongoDB Java Driver 的超时参数来规避这个问题。
但经过详细分析之后，这样是无法根治问题的，而且超时配置应该如何调整也难以评估。
下面是关于对这个问题的分析、调优的过程。
初步分析
从出错的信息上看，是数据库的操作响应超时了，此时客户端配置的 SocketReadTimeout 为 60s。
那么，是什么操作会导致数据库 60s 还没能返回呢？
业务操作
左边的数据库是一个工单数据表(t_work_order)，其中记录了每张工单的信息，包括工单编号(oid)、最后修改时间(lastModifiedTime)
分析服务是Java实现的一个应用程序，在每天凌晨1:00 会拉取出前一天修改的工单信息(要求按工单号排序)进行处理。
由于工单表非常大(千万级)，所以在处理时会采用分页的做法(每次取1000条)，使用按工单号翻页的方式：
第一次拉取
索引seeks的原因官方文档对于 seeks 的解释如下：
The number of times that we had to seek the index cursor to a new position in order to complete the index scan.
翻译过来就是：
seeks 是指为了完成索引扫描(stage)，执行器必须将游标定位到新位置的次数。
我们都知道 MongoDB 的索引是B+树的实现(3.x以上)，对于连续的叶子节点扫描来说是非常快的(只需要一次寻址)，那么seeks操作太多则表示整个扫描过程中出现了大量的寻址(跳过非目标节点)。
而且，这个seeks指标是在3.4版本支持的，因此可以推测该操作对性能是存在影响的。
为了探究 seeks 是怎么产生的，我们对查询语句尝试做了一些变更：
去掉 exists 条件
exists 条件的存在是因为历史问题(一些旧记录并不包含工单号的字段)，为了检查exists查询是否为关键问题，修改如下：
在不存在exists条件的情况下，执行器选择了叶节点顺序扫描的方式，如下图：
gt 条件和反序
除了第一次查询之外，我们对后续的分页查询也进行了分析，如下：
反序，从后面开始检索
优化思路
通过分析，我们知道了问题的症结在于索引的扫描范围过大，那么如何优化，以避免扫描大量记录呢？
从现有的索引及条件来看，由于同时存在gt、exists以及叶子节点的时间范围限定，不可避免的会产生seeks操作，
而且查询的性能是不稳定的，跟数据分布、具体查询条件都有很大的关系。
于是一开始所提到的仅仅是增加 socketTimeout 的阈值可能只是治标不治本，一旦数据的索引值分布变化或者数据量持续增大，可能会发生更严重的事情。
回到一开始的需求场景，定时器要求读取每天更新的工单(按工单号排序)，再进行分批处理。
那么，按照化零为整的思路，新增一个lastModifiedDay字段，这个存储的就是lastModifiedTime对应的日期值(低位取整)，这样在同一天内更新的工单记录都有同样的值。
建立组合索引 {lastModifiedDay:1, oid:1}，相应的查询条件改为：
小结本质上，这就是一种空间换时间的方法，即通过存储一个额外的索引字段来加速查询，通过增加少量的存储开销提升了整体的效能。
在对于许多问题进行优化时，经常是需要从应用场景触发，适当的转换思路。
比如在本文的问题中，是不是一定要增加字段呢？如果业务上可以接受不按工单号排序进行读取，那么仅使用更新时间字段进行分页拉取也是可以达到效果的，具体还是要由业务场景来定。
本篇文章到此结束，如果您有相关技术方面疑问可以联系我们技术人员远程解决，感谢大家支持本站！
