如何通过缓存+SQL修改优化慢查询

本篇内容介绍了“如何通过缓存+SQL修改优化慢查询”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

问题描述

单例数据库模式中，后端高并发请求多（读多写少），导致数据库压力过大，关键接口响应变慢，严重影响体验。

需求

减少接口的响应时间。

寻找解决方案

由于问题主要处在数据库压力过大的情况，采用两种优化思路优化查询过程：

• 使用缓存分担数据库压力

• 对查询数据库过程做优化

缓存方案

更新策略

使用Redis，虽然可以很好地减少数据库的压力，但是同时在高并发的情况下，容易出现数据不一致的情况，尤其是在更新数据的时候。

最常见的导致不一致的原因是双写操作，即高并发情况下短时间内对数据库进行两次写操作。为了最小程度地出现这种情况，缓存在更新策略上采用先更新数据库后删除缓存的方式。

对于双写问题，在最坏情况下，写请求A在更新数据库后，被写请求B先一步更新数据库+删除缓存，然后A请求才删除缓存，也不会导致后续请求读取到错误的值。

对于先写后读，在最坏情况下，写请求A在更新数据库后，被读请求C先一步在缓存读取到旧值，然后A请求才删除缓存，也只会影响这段时间的读请求，删除后的读请求不影响。

对比其他方案（先更新缓存后更新数据库、先删除缓存后更新数据库、先更新数据库后更新缓存）在最坏情况下会导致的错误（更新数据库失败导致缓存是未知值、双写后数据库变成旧值、更新缓存失败导致缓存保存旧值）要好得多。

但是先更新数据库后删除缓存也不是完全安全的，除了上文提到的高并发下先写后读可能读到旧值外，若删除缓存失败，也有可能导致读到旧值。处理方法见下文。

缓存架构

添加缓存，势必要修改业务代码，如何配置架构才能把对代码的入侵性讲到最低，这里使用监听数据库binlog的方法，使用中间件监听mysql的日志，当出现操作时，通知专门的模块来修改缓存，做到修改缓存和业务逻辑解耦。

同时为了解决缓存删除失败的问题，当发生失败时，发送消息至消息队列传递给专门的模块进行重试删除。

中间件选择：

• 缓存使用Redis

• 监听binlog使用canal

• 消息队列使用RocketMQ

架构如下所示：

SQL优化

查询优化可以从两个方面进行：

• 根据高频的查询case，遵循最左匹配原则，设置对应的索引或联合索引

• 通过了解业务场景，看看能否将一些小SQL合并成大SQL

“如何通过缓存+SQL修改优化慢查询”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注蜗牛博客网站，小编将为大家输出更多高质量的实用文章！

免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：niceseo99@gmail.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。