溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“如何通過緩存+SQL修改優化慢查詢”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
單例數據庫模式中，后端高并發請求多（讀多寫少），導致數據庫壓力過大，關鍵接口響應變慢，嚴重影響體驗。
減少接口的響應時間。
由于問題主要處在數據庫壓力過大的情況，采用兩種優化思路優化查詢過程：
使用緩存分擔數據庫壓力
對查詢數據庫過程做優化
使用Redis，雖然可以很好地減少數據庫的壓力，但是同時在高并發的情況下，容易出現數據不一致的情況，尤其是在更新數據的時候。
最常見的導致不一致的原因是雙寫操作，即高并發情況下短時間內對數據庫進行兩次寫操作。為了最小程度地出現這種情況，緩存在更新策略上采用先更新數據庫后刪除緩存的方式。
對于雙寫問題，在最壞情況下，寫請求A在更新數據庫后，被寫請求B先一步更新數據庫+刪除緩存，然后A請求才刪除緩存，也不會導致后續請求讀取到錯誤的值。
對于先寫后讀，在最壞情況下，寫請求A在更新數據庫后，被讀請求C先一步在緩存讀取到舊值，然后A請求才刪除緩存，也只會影響這段時間的讀請求，刪除后的讀請求不影響。
對比其他方案（先更新緩存后更新數據庫、先刪除緩存后更新數據庫、先更新數據庫后更新緩存）在最壞情況下會導致的錯誤（更新數據庫失敗導致緩存是未知值、雙寫后數據庫變成舊值、更新緩存失敗導致緩存保存舊值）要好得多。
但是先更新數據庫后刪除緩存也不是完全安全的，除了上文提到的高并發下先寫后讀可能讀到舊值外，若刪除緩存失敗，也有可能導致讀到舊值。處理方法見下文。
添加緩存，勢必要修改業務代碼，如何配置架構才能把對代碼的入侵性講到最低，這里使用監聽數據庫binlog的方法，使用中間件監聽mysql的日志，當出現操作時，通知專門的模塊來修改緩存，做到修改緩存和業務邏輯解耦。
同時為了解決緩存刪除失敗的問題，當發生失敗時，發送消息至消息隊列傳遞給專門的模塊進行重試刪除。
中間件選擇：
緩存使用Redis
監聽binlog使用canal
消息隊列使用RocketMQ
架構如下所示：
查詢優化可以從兩個方面進行：
根據高頻的查詢case，遵循最左匹配原則，設置對應的索引或聯合索引
通過了解業務場景，看看能否將一些小SQL合并成大SQL
“如何通過緩存+SQL修改優化慢查詢”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
