Mysql数据库未添加索引引发的生产事故
最近开发的新功能主要是首页的红点提示功能,某个用户登录系统app,然后进入某一个功能模块,
在该功能下面有很多地方可以操作,新功能就是根据用户信息查询当月是否存在新的数据。总共有四五
个地方如果出现增量数据时,需要红点提示。自己所在的项目组B主要是数据提供方,关联的项目组A
调用我们的接口获取数据,然后在做相应的逻辑处理,大致是这么一个流程。
根据关联方描述,大致的逻辑是第一次查询的时候,所有功能都添加红点提示,并且在数据库和
Redis缓存中记录一个红点查询的最大时间。当用户再次进入该页面,根据调用B项目组提供的
接口的数据进行比对,返回的最大时间大于A项目原有Redis中记录的最大时间,则表示有新数据。
如果返回的最大时间小于等于A项目原有Redis中记录的最大时间,则表示没有新数据。除了这个
逻辑处理之外,这个接口A项目组还有其他逻辑需要处理。
周五发版之后,周末两天都正常,没出什么问题,安心过周末。可是等到周一去到公司之后,
负责人在群里面发消息说App对应的功能模块页面加载不出来,还发了一张截图,一直在那里转
圈圈。看到这个消息,自己就知道大事不好,肯定出现性能问题才导致这种情况。原计划周一开的
会也立即取消,立马去找A项目组的人员排查问题,解决问题。
大概过了两天之后,再次开会时,他们才提起这个问题,主要就是性能不好导致的。项目组A
使用的是Mysql数据库,由于周一正式开始上班,大量人员开始使用app,导致查询红点的那个接口
性能急剧下降,然后就一直在转圈圈。听他们说他们临时的处理办法是,给Mysql中记录红点功能的
表添加一个索引,查询效率提升之后,问题也随之解决。听到这个结果,还是让自己挺意外的。那张
表总的数据量200w不到,而且每个用户约有5个红点,每次查询需要更新5次数据库数据和redis
缓存数据,将其更新为最新查询时间。由于需要频繁的进行更新操作,而且那个接口处理的逻辑还
比较复杂,他们一开始开发的时候,也没有添加索引,因此导致这个生产事故。
听到这个原因难免有些意外,可是这就是导致出现问题的直接原因。出现这种问题算是比较严重
的生产事故,最明显的提现就是对员工个人绩效考核的时候,薪资会受影响。也算是给自己上了一课,
数据库加索引很不不加索引的区别,不过前提是正确地添加索引,添加在正确的字段上才会有效果。
在讨论这个问题的时候,我们这边的负责人还给出了一个优化方案,当用户直接请求时,获取红点接口
数据,可直接先操作Redis,然后通过异步线程将最新查询时间更新到Mysql数据库,这样既提高了
接口的处理效率,同时也将最新数据更新到了数据库中。自己还是比较赞同这种方式,如果以后
遇到类似的问题,则可以采用相同的解决办法。