sql一次查詢需要關聯十幾張表，有什麼優化方案麼？

2020-02-12 00:19:10 佚名

不知道開發的同學有沒有遇到過類似這樣的需求：

那麼此類需求要如何滿足呢？我們選擇了“通過 ETL 提前進行數據整合”的方案。

什麼是 ETL

說到ETL，很多開發夥伴可能會有些陌生，更多的時候 ETL 是用在大數據、數據分析的相關崗位；我也是在近幾年的工作過程中才接觸到ETL的，現在的項目比較依賴 ETL，可以說是項目中重要的一部分。

ETL 是三個單詞的縮寫：

從這三個單詞基本可以瞭解 ETL 的作用：將各個業務系統的數據，通過抽取、清洗、轉換之後，將加工後的數據落地到數據庫中（數據倉庫）；在這個過程中，ETL 可以將分散、零亂、標準不統一的數據整合到一起。

我接觸過的項目，使用ETL工具的場景有這個幾種：

1. 報表、BI系統：

在公司建設的初期，業務比較少，系統也比較少，一臺數據庫就搞定了；隨著公司業務的增加，業務系統被拆成很多系統；隨著數據量的繼續增加，單個系統的數據增加到一定程度的時候，也做了分庫分表；

這時候領導、業務人員在用數據做分析的時候，數據來源可能是多個系統的多張表，這時候企圖通過一個複雜的 SQL 跑出來結果就很困難了；通常公司會建立一個數據倉庫，通過ETL工具把數據抽取到數據倉庫中，再做數據的擬合和展示。

2. 跨系統的數據加工或查詢：

我們現在所在公司，業務系統有幾百個，由於業務流程比較複雜，前端系統在做業務操作的時候，在正式提交交易之前，有很多業務校驗；

比如要查詢客戶在 X 系統的交易歷史，在 Y 系統的交易歷史，在 Z 系統的交易歷史；那麼就需要分別調用 X、Y、Z 系統的接口，這個對前端系統很不友好，那麼通常的解決方案是什麼？

A 方案：做一箇中間服務，中間服務去調用 X、Y、Z 系統的接口，客戶端直接調用這個中間服務；這種方案只是把前端要做的事情，轉移到了中間服務；
B 方案：整合 X、Y、Z 三個系統，建服務中臺；這種方法很好，但是極為難，對於很多公司來說，別說把 X、Y、Z 三個系統整合成一箇中臺系統，就是其中一個系統本身進行重構，都是非常困難的；
C 方案：把 X、Y、Z 三個系統中需要的數據，通過 ETL 抽取加工到一個數據倉庫中，對外提供服務；這個系統最大的好處是在不改造 X、Y、Z 三個系統的前提下，又可以實現跨系統的查詢。

我們在 C 方案的基礎上又往前做了一步，就是將落地後的數據又做了一次加工，將需要跨表關聯的數據，提前關聯好存入 MongoDB 中，對外提供查詢服務；這樣可以將多表關聯查詢，變成了單表查詢。

接上文中第二個例子中的 C 方案，有些同學可能會有個疑問：數據抽取，需要抽取哪些數據呢？為什麼不讓這些系統把數據吐出來呢？

答案也簡單，“有的時候，數據不一定能吐出來”。

MySQL 數據庫往外吐數據有比較成熟的中間件，比如 Canal，它可以通過監聽 Mysql 的 binlog 日誌來獲取數據，binlog 設置為 row 模式，能夠獲取到每一條新增、刪除、修改的日誌，同時還能獲取到修改前後的數據；
其他商用數據庫，比如 Oracle、DB2 等，我也查閱過相關的資料，也是有觸發器機制，可以當數據發生變化的時候通知出來，比如調用一段程序，將數據發送到消息隊列中，再由其他程序監聽消息隊列做後續處理。

不管什麼類型的數據庫，這種“吐數據”的方案，對於基礎設施的要求都比較高，並且對原有系統有一定的侵入性；所以我們採用了對原有系統侵入性更小的方案：主動抽數據。

1. 優點

2. 缺點

不知道你這十關聯的十幾個表數據量有多大，按照我現在操作是萬級別的數據，速度是不慢的，因為我關聯的都是主鍵關係，實在不行可以考慮拆分成多條SQL語句

良好的設計數據庫，這種情況往往是糟糕的數據庫設計的問題。找個對數據庫有深入瞭解大牛，幫忙規劃一下，要不了幾天，但很解決問題。

這種情況一般都是因為前期設計沒做好。。數據結構重構一遍吧。。。。

或者分開查。連表的邏輯放到程序裡做。。

分享到: