Mysql数据库未添加索引引发的生产事故

　　最近开发的新功能主要是首页的红点提示功能，某个用户登录系统app，然后进入某一个功能模块，

在该功能下面有很多地方可以操作，新功能就是根据用户信息查询当月是否存在新的数据。总共有四五

个地方如果出现增量数据时，需要红点提示。自己所在的项目组B主要是数据提供方，关联的项目组A

调用我们的接口获取数据，然后在做相应的逻辑处理，大致是这么一个流程。

　　根据关联方描述，大致的逻辑是第一次查询的时候，所有功能都添加红点提示，并且在数据库和

Redis缓存中记录一个红点查询的最大时间。当用户再次进入该页面，根据调用B项目组提供的

接口的数据进行比对，返回的最大时间大于A项目原有Redis中记录的最大时间，则表示有新数据。

如果返回的最大时间小于等于A项目原有Redis中记录的最大时间，则表示没有新数据。除了这个

逻辑处理之外，这个接口A项目组还有其他逻辑需要处理。

　　周五发版之后，周末两天都正常，没出什么问题，安心过周末。可是等到周一去到公司之后，

负责人在群里面发消息说App对应的功能模块页面加载不出来，还发了一张截图，一直在那里转

圈圈。看到这个消息，自己就知道大事不好，肯定出现性能问题才导致这种情况。原计划周一开的

会也立即取消，立马去找A项目组的人员排查问题，解决问题。

　　大概过了两天之后，再次开会时，他们才提起这个问题，主要就是性能不好导致的。项目组A

使用的是Mysql数据库，由于周一正式开始上班，大量人员开始使用app，导致查询红点的那个接口

性能急剧下降，然后就一直在转圈圈。听他们说他们临时的处理办法是，给Mysql中记录红点功能的

表添加一个索引，查询效率提升之后，问题也随之解决。听到这个结果，还是让自己挺意外的。那张

表总的数据量200w不到，而且每个用户约有5个红点，每次查询需要更新5次数据库数据和redis

缓存数据，将其更新为最新查询时间。由于需要频繁的进行更新操作，而且那个接口处理的逻辑还

比较复杂，他们一开始开发的时候，也没有添加索引，因此导致这个生产事故。

　　听到这个原因难免有些意外，可是这就是导致出现问题的直接原因。出现这种问题算是比较严重

的生产事故，最明显的提现就是对员工个人绩效考核的时候，薪资会受影响。也算是给自己上了一课，

数据库加索引很不不加索引的区别，不过前提是正确地添加索引，添加在正确的字段上才会有效果。

在讨论这个问题的时候，我们这边的负责人还给出了一个优化方案，当用户直接请求时，获取红点接口

数据，可直接先操作Redis，然后通过异步线程将最新查询时间更新到Mysql数据库，这样既提高了

接口的处理效率，同时也将最新数据更新到了数据库中。自己还是比较赞同这种方式，如果以后

遇到类似的问题，则可以采用相同的解决办法。