使用查詢分離後，從20s最佳化到500ms，牛哇~

2025-06-24 14:54 芋道原始碼

👉 這是一個或許對你有用的社群
🐱 一對一交流/面試小冊/簡歷最佳化/求職解惑，歡迎加入「芋道快速開發平臺」知識星球。下面是星球提供的部分資料：
👉這是一個或許對你有用的開源專案
國產 Star 破 10w+ 的開源專案，前端包括管理後臺 + 微信小程式，後端支援單體和微服務架構。
功能涵蓋 RBAC 許可權、SaaS 多租戶、資料許可權、商城、支付、工作流、大屏報表、微信公眾號、CRM 等等功能：
  • Boot 倉庫：https://gitee.com/zhijiantianya/ruoyi-vue-pro
  • Cloud 倉庫：https://gitee.com/zhijiantianya/yudao-cloud
  • 影片教程：https://doc.iocoder.cn
【國內首批】支援 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 雙版本 
來源：碼猿技術專欄
本文我們來說說使用 查詢分離 最佳化業務主表資料大查詢緩慢的問題

什麼是查詢分離？

查詢分離從字面上來說非常容易理解，其實就是在寫資料時儲存一個備份資料到另外的儲存系統，在查詢時直接從另外的儲存系統中獲取資料，如下圖：
查詢分離
以上只是簡單的架構圖，其中有些細節還是需要深究，如下：
  1. 什麼時候觸發查詢分離？
  2. 如何實現查詢分離？
  3. 查詢資料的儲存系統選型？
  4. 查詢資料如何使用？
基於 Spring Boot + MyBatis Plus + Vue & Element 實現的後臺管理系統 + 使用者小程式，支援 RBAC 動態許可權、多租戶、資料許可權、工作流、三方登入、支付、簡訊、商城等功能
  • 專案地址：https://github.com/YunaiV/ruoyi-vue-pro
  • 影片教程：https://doc.iocoder.cn/video/

查詢分離的適用場景？

當你在實際業務中遇到以下情形，則可以考慮使用查詢分離解決方案。
  • 資料量大；
  • 所有寫資料的請求效率尚可；
  • 查詢資料的請求效率很低；
  • 所有的資料任何時候都可能被修改；
  • 業務希望我們最佳化查詢資料的功能。
曾做過 SaaS 客服系統的架構最佳化，系統裡有一個工單查詢功能，工單表中存放了幾千萬條資料，且查詢工單表資料時需要關聯十幾個子表，每個子表的資料也是超億條。
面對如此龐大的資料量，跟前面的冷熱分離一樣，每次客戶查詢資料時幾十秒才能返回結果，即便我們使用了索引、SQL 等資料庫最佳化技巧，效果依然不明顯。
工單表中有些資料是幾年前的，客戶說這些資料涉及訴訟問題，需要繼續保持更新，因此我們無法將這些舊資料封存到別的地方，也就沒法透過前面的冷熱分離方案來解決。
最終我們採用了查詢分離的解決方案，才得以將這個問題順利解決：將更新的資料放在一個數據庫裡，而查詢的資料放在另外一個系統裡。因為資料的更新都是單表更新，不需要關聯也沒有外部索引鍵，所以更新速度立馬得到提升，每次客戶查詢資料時，500ms 內就可得到返回結果。
基於 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的後臺管理系統 + 使用者小程式，支援 RBAC 動態許可權、多租戶、資料許可權、工作流、三方登入、支付、簡訊、商城等功能
  • 專案地址：https://github.com/YunaiV/yudao-cloud
  • 影片教程：https://doc.iocoder.cn/video/

什麼時候觸發查詢分離？

簡單的來說就是什麼時候應該儲存一份資料到查詢資料庫中，其實也就是資料異構的過程。
這裡介紹三種方式，如下：
  1. 同步建立
  2. 非同步建立
  3. binlog方式

1、 同步建立

修改業務程式碼：在寫入常規資料後，同步建立查詢資料。
該種方案優缺點也非常明顯：
優點 ：查詢資料的一致性和即時性得到了保證
缺點 ：業務程式碼侵入比較強；減緩寫操作的效率

2、 非同步建立

修改業務程式碼：寫入資料後，非同步建立查詢資料
該種方案的優缺點如下：
優點 ：不影響主流程
缺點 ：資料一致性存在問題

3、 binlog的方式

該種方案也是業界常用的一種方案，對於程式碼是無侵入的，透過監聽資料庫日誌的方式建立查詢資料，如下：
該種方案的優缺點如下：
優點 ：不影響主流程；程式碼侵入為0
缺點 ：資料一致性存在問題；架構相對複雜

如何實現查詢分離？

這篇文章來介紹一下非同步的方式，非同步的方式有很多，可以放在記憶體中進行操作，但是這有些弊端：
  1. 資料過多，記憶體有限
  2. 服務重啟，記憶體資料將會丟失
因此最終我們可以選擇MQ 的方式，那麼此時就涉及到了MQ的技術選型，這裡給兩個建議：
  1. 如果你的公司已經用了MQ，那麼直接接著用即可
  2. 如果公司目前未引入MQ，則需要架構組考量選型了，
當然一旦引入了MQ還需要考慮的問題很多，如下：

1、 MQ突然宕機了怎麼辦？

MQ宕機意味著查詢資料不能繼續建立了，我們可以在寫入資料的同時給該條資料加一個標誌欄位（已搬運、未搬運），當MQ啟動後，查詢所有未搬運的資料，繼續建立查詢資料
“
這裡的方案很多，按照業務實際情況考量
”

2、訊息的冪等消費

訊息的冪等消費一定要保證，避免資料重複建立，比如：主資料的訂單 A 更新後，我們在查詢資料中插入了 A，可是此時系統出問題了，系統誤以為查詢資料沒更新，又把訂單 A 插入更新了一次。

3、訊息的時序性問題

比如某個訂單 A 更新了 1 次資料變成 A1，執行緒甲將 A1 的資料搬到查詢資料中。不一會兒，後臺訂單 A 又更新了 1 次資料變成 A2，執行緒乙也啟動工作，將 A2 的資料搬到查詢資料中。
所謂的時序性就是如果執行緒甲啟動比乙早，但搬運資料動作比執行緒乙還晚完成，就有可能出現查詢資料最終變成過期的 A1

查詢資料的儲存系統選型？

既然為了解決表資料量大查詢緩慢的問題，肯定是不能選用關係型資料庫了，那麼還有其他選擇嗎？
記憶體資料庫雖然效能非常高，比如Redis，但是不適合海量資料，太費錢了
那麼這裡比較適用的有如下三種：
  1. MongoDB
  2. HBase
  3. Elasticsearch
這裡選型還是要根據自己公司業務選擇，如果已經有在用的，則直接用即可；另外就是選擇自己熟悉的，比如當初我們設計架構方案時，為什麼選擇用 Elasticsearch，除 ES 對查詢的擴充套件性支援外，最關鍵的一點是我們團隊對 Elasticsearch 很熟悉。

查詢資料如何使用？

查詢資料很簡單，每個資料庫都有對應的API，直接呼叫查詢
但是，這裡有一個問題：資料查詢更新完前，查詢資料不一致怎麼辦？ ，給出兩種方案：
  1. 在查詢資料更新到最新前，不允許使用者查詢。（我們沒用過這種設計，但我確實見過市面上有這樣的設計。）
  2. 給使用者提示：您目前查詢到的資料可能是 1 秒前的資料，如果發現數據不準確，可以嘗試重新整理一下，這種提示使用者一般比較容易接受。

總結

本篇文章介紹了表資料量大查詢緩慢的一種解決方案：查詢分離，但這也不是銀彈，仍然是存在一些不足，比如表資料量大，寫入緩慢怎麼辦？這個後面文章再介紹吧
當然查詢分離還有一個重要的問題：歷史資料如何遷移？這個處理也是非常簡單，但是也有許多需要考慮的點，後文介紹
歡迎加入我的知識星球，全面提升技術能力。
👉 加入方式，“長按”或“掃描”下方二維碼噢：
星球的內容包括：專案實戰、面試招聘、原始碼解析、學習路線。
文章有幫助的話，在看，轉發吧。
謝謝支援喲 (*^__^*）
關鍵詞
系統
功能
資料庫
使用者
專案


相關文章