«

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

时间:2024-7-13 14:22     作者:韩俊     分类: Mysql


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

    问题描述

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

    需求

    减少接口的响应时间。

    寻找解决方案

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

      使用缓存分担数据库压力

      对查询数据库过程做优化

    缓存方案

    更新策略

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

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

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

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

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

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

    缓存架构

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

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

    中间件选择:

      缓存使用Redis

      监听binlog使用canal

      消息队列使用RocketMQ

    架构如下所示:

    SQL优化

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

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

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

    标签: mysql

    热门推荐