不知道開(kāi)發(fā)的同學(xué)有沒(méi)有遇到過(guò)類似這樣的需求：

• 相同類型的數(shù)據(jù)在多個(gè)系統(tǒng)中，如果要得到全部的信息，就要連續(xù)調(diào)多個(gè)系統(tǒng)的接口；

• 業(yè)務(wù)復(fù)雜，一個(gè)需求需要關(guān)聯(lián)幾張表甚至幾十張表才能得到想要的結(jié)果；

• 系統(tǒng)做了分庫(kù)分表，但是需要統(tǒng)計(jì)所有的數(shù)據(jù)。

那么此類需求要如何滿足呢？我們選擇了“通過(guò) ETL 提前進(jìn)行數(shù)據(jù)整合”的方案。

什么是 ETL

說(shuō)到ETL，很多開(kāi)發(fā)伙伴可能會(huì)有些陌生，更多的時(shí)候 ETL 是用在大數(shù)據(jù)、數(shù)據(jù)分析的相關(guān)崗位；我也是在近幾年的工作過(guò)程中才接觸到ETL的，現(xiàn)在的項(xiàng)目比較依賴 ETL，可以說(shuō)是項(xiàng)目中重要的一部分。

ETL 是三個(gè)單詞的縮寫：

• Extraction：抽取、提?。痪褪前褦?shù)據(jù)從數(shù)據(jù)庫(kù)里面取出來(lái)；

• Transformation：轉(zhuǎn)換；包括但不限于：數(shù)據(jù)篩選校驗(yàn)、數(shù)據(jù)關(guān)聯(lián)、數(shù)據(jù)內(nèi)容及結(jié)構(gòu)的修改、運(yùn)算、統(tǒng)計(jì)等等；

• Loading：加載；將處理后的數(shù)據(jù)保存到目標(biāo)數(shù)據(jù)庫(kù)。

從這三個(gè)單詞基本可以了解 ETL 的作用：將各個(gè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，通過(guò)抽取、清洗、轉(zhuǎn)換之后，將加工后的數(shù)據(jù)落地到數(shù)據(jù)庫(kù)中（數(shù)據(jù)倉(cāng)庫(kù)）；在這個(gè)過(guò)程中，ETL 可以將分散、零亂、標(biāo)準(zhǔn)不統(tǒng)一的數(shù)據(jù)整合到一起。

使用場(chǎng)景

我接觸過(guò)的項(xiàng)目，使用ETL工具的場(chǎng)景有這個(gè)幾種：

1. 報(bào)表、BI系統(tǒng)：

在公司建設(shè)的初期，業(yè)務(wù)比較少，系統(tǒng)也比較少，一臺(tái)數(shù)據(jù)庫(kù)就搞定了；隨著公司業(yè)務(wù)的增加，業(yè)務(wù)系統(tǒng)被拆成很多系統(tǒng)；隨著數(shù)據(jù)量的繼續(xù)增加，單個(gè)系統(tǒng)的數(shù)據(jù)增加到一定程度的時(shí)候，也做了分庫(kù)分表；

這時(shí)候領(lǐng)導(dǎo)、業(yè)務(wù)人員在用數(shù)據(jù)做分析的時(shí)候，數(shù)據(jù)來(lái)源可能是多個(gè)系統(tǒng)的多張表，這時(shí)候企圖通過(guò)一個(gè)復(fù)雜的 SQL 跑出來(lái)結(jié)果就很困難了；通常公司會(huì)建立一個(gè)數(shù)據(jù)倉(cāng)庫(kù)，通過(guò)ETL工具把數(shù)據(jù)抽取到數(shù)據(jù)倉(cāng)庫(kù)中，再做數(shù)據(jù)的擬合和展示。

2. 跨系統(tǒng)的數(shù)據(jù)加工或查詢：

我們現(xiàn)在所在公司，業(yè)務(wù)系統(tǒng)有幾百個(gè)，由于業(yè)務(wù)流程比較復(fù)雜，前端系統(tǒng)在做業(yè)務(wù)操作的時(shí)候，在正式提交交易之前，有很多業(yè)務(wù)校驗(yàn)；

比如要查詢客戶在 X 系統(tǒng)的交易歷史，在 Y 系統(tǒng)的交易歷史，在 Z 系統(tǒng)的交易歷史；那么就需要分別調(diào)用 X、Y、Z 系統(tǒng)的接口，這個(gè)對(duì)前端系統(tǒng)很不友好，那么通常的解決方案是什么？

• A 方案：做一個(gè)中間服務(wù)，中間服務(wù)去調(diào)用 X、Y、Z 系統(tǒng)的接口，客戶端直接調(diào)用這個(gè)中間服務(wù)；這種方案只是把前端要做的事情，轉(zhuǎn)移到了中間服務(wù)；

• B 方案：整合 X、Y、Z 三個(gè)系統(tǒng)，建服務(wù)中臺(tái)；這種方法很好，但是極為難，對(duì)于很多公司來(lái)說(shuō)，別說(shuō)把 X、Y、Z 三個(gè)系統(tǒng)整合成一個(gè)中臺(tái)系統(tǒng)，就是其中一個(gè)系統(tǒng)本身進(jìn)行重構(gòu)，都是非常困難的；

• C 方案：把 X、Y、Z 三個(gè)系統(tǒng)中需要的數(shù)據(jù)，通過(guò) ETL 抽取加工到一個(gè)數(shù)據(jù)倉(cāng)庫(kù)中，對(duì)外提供服務(wù)；這個(gè)系統(tǒng)最大的好處是在不改造 X、Y、Z 三個(gè)系統(tǒng)的前提下，又可以實(shí)現(xiàn)跨系統(tǒng)的查詢。

我們?cè)?C 方案的基礎(chǔ)上又往前做了一步，就是將落地后的數(shù)據(jù)又做了一次加工，將需要跨表關(guān)聯(lián)的數(shù)據(jù)，提前關(guān)聯(lián)好存入 MongoDB 中，對(duì)外提供查詢服務(wù)；這樣可以將多表關(guān)聯(lián)查詢，變成了單表查詢。

吐數(shù)據(jù) VS 抽數(shù)據(jù)

接上文中第二個(gè)例子中的 C 方案，有些同學(xué)可能會(huì)有個(gè)疑問(wèn)：數(shù)據(jù)抽取，需要抽取哪些數(shù)據(jù)呢？為什么不讓這些系統(tǒng)把數(shù)據(jù)吐出來(lái)呢？

答案也簡(jiǎn)單，“有的時(shí)候，數(shù)據(jù)不一定能吐出來(lái)”。

• MySQL 數(shù)據(jù)庫(kù)往外吐數(shù)據(jù)有比較成熟的中間件，比如 Canal，它可以通過(guò)監(jiān)聽(tīng) Mysql 的 binlog 日志來(lái)獲取數(shù)據(jù)，binlog 設(shè)置為 row 模式，能夠獲取到每一條新增、刪除、修改的日志，同時(shí)還能獲取到修改前后的數(shù)據(jù)；

• 其他商用數(shù)據(jù)庫(kù)，比如 Oracle、DB2 等，我也查閱過(guò)相關(guān)的資料，也是有觸發(fā)器機(jī)制，可以當(dāng)數(shù)據(jù)發(fā)生變化的時(shí)候通知出來(lái)，比如調(diào)用一段程序，將數(shù)據(jù)發(fā)送到消息隊(duì)列中，再由其他程序監(jiān)聽(tīng)消息隊(duì)列做后續(xù)處理。

不管什么類型的數(shù)據(jù)庫(kù)，這種“吐數(shù)據(jù)”的方案，對(duì)于基礎(chǔ)設(shè)施的要求都比較高，并且對(duì)原有系統(tǒng)有一定的侵入性；所以我們采用了對(duì)原有系統(tǒng)侵入性更小的方案：主動(dòng)抽數(shù)據(jù)。

ETL 方案的優(yōu)缺點(diǎn)

1. 優(yōu)點(diǎn)

• 侵入性較低，數(shù)據(jù)源系統(tǒng)只需要開(kāi)通數(shù)據(jù)庫(kù)的訪問(wèn)權(quán)限即可，為保證數(shù)據(jù)抽取對(duì)業(yè)務(wù)的影響，通常是訪問(wèn)源系統(tǒng)的備庫(kù)，并且多帶帶設(shè)置一個(gè)只讀權(quán)限的數(shù)據(jù)庫(kù)用戶；

• 支持不同類型數(shù)據(jù)源的數(shù)據(jù)抽取，比如源庫(kù)有 Mysql、DB2、Oracle，通過(guò) ETL 也可以輕松搞定；

• 數(shù)據(jù)整合，將不同業(yè)務(wù)系統(tǒng)的相同數(shù)據(jù)整合在一起，比如有些系統(tǒng) M/F 表示男女，有些系統(tǒng) 1/0 表示男女，ETL 在抽取加工后轉(zhuǎn)換成統(tǒng)一的編碼；

2. 缺點(diǎn)

• 比較致命的一個(gè)缺點(diǎn)，就是數(shù)據(jù)抽取和加工有一定的延遲，需要根據(jù)業(yè)務(wù)場(chǎng)景進(jìn)行評(píng)估，是否接受這個(gè)延遲；

• 可能會(huì)受到源庫(kù)表結(jié)構(gòu)變化的影響；

• 如果源庫(kù)中的表沒(méi)有時(shí)間戳，或者時(shí)間戳不準(zhǔn)確，那么增量抽取就變得很困難；

• 需要招聘 ETL 開(kāi)發(fā)崗，從我目前的經(jīng)驗(yàn)看，不是特別好招。

我將持續(xù)分享Java開(kāi)發(fā)、架構(gòu)設(shè)計(jì)、程序員職業(yè)發(fā)展等方面的見(jiàn)解，希望能得到你的關(guān)注。

關(guān)聯(lián)表都是有復(fù)雜度的，一般不超過(guò)三個(gè)，不然后期維護(hù)很難看懂邏輯。

sql優(yōu)化

可以試試拆分sql，在代碼里多次查詢?cè)僦麈I關(guān)聯(lián)，最后合并數(shù)據(jù)。

索引

如果很慢的話可以調(diào)查一下是不是sql有笛卡爾積現(xiàn)象，沒(méi)有加主鍵或缺少索引。一般查詢慢都是缺少索引，或者索引沒(méi)用上。

分頁(yè)

業(yè)務(wù)邏輯上要加分頁(yè)，不要一次查太大量的數(shù)據(jù)。

我記得ucloud巴巴開(kāi)發(fā)手冊(cè)規(guī)定了一次join不能超過(guò)3張表，為什么會(huì)有這種規(guī)范，顯然是在某種業(yè)務(wù)場(chǎng)景下要多做數(shù)據(jù)冗余，方便查詢，性能更高，帶來(lái)的缺點(diǎn)就是更新可能會(huì)更復(fù)雜，而三范式結(jié)構(gòu)更清晰，數(shù)據(jù)量大性能必然會(huì)下降，所以要有取舍，設(shè)計(jì)表結(jié)構(gòu)時(shí)，要三范式和反范式結(jié)合而用，否則那些頭部互聯(lián)網(wǎng)公司哪個(gè)業(yè)務(wù)不復(fù)雜，雖然可以用es和hbase，但如果都是join十多張表那都不用玩了，我所在的物流公司，業(yè)務(wù)也是非常復(fù)雜，剛來(lái)公司的時(shí)候就發(fā)現(xiàn)，前期表結(jié)構(gòu)規(guī)劃不合理，也沒(méi)有采用es等中間件做數(shù)據(jù)聚合，一個(gè)簡(jiǎn)單的例子，掃條碼碼入庫(kù)，全鏈路壓測(cè)吞吐連10都不到，走讀下代碼，一個(gè)獲取訂單信息的查詢10張表，整個(gè)流程中還有多個(gè)系統(tǒng)的同步調(diào)用，基本上隨便都是七八張表以上，本身也是個(gè)新項(xiàng)目，跑了一年左右了，量沒(méi)有特別大，但是業(yè)務(wù)復(fù)雜的牽一發(fā)動(dòng)全身，這種系統(tǒng)就別想重構(gòu)了，大公司你懂的，所以首先就是各種sql優(yōu)化，能提高多少是多少，待了半年左右就走了，再待下去量上來(lái)，系統(tǒng)扛不住，天天就得加班挨叼了。所以說(shuō)一個(gè)好的設(shè)計(jì)，至少可以讓你系統(tǒng)能抗的住未來(lái)一兩年的業(yè)務(wù)的增長(zhǎng)。

給你三個(gè)建議

建議一：

你應(yīng)該找需求人員，了解清楚需求，看看能否減少關(guān)聯(lián)表

建議二：

關(guān)聯(lián)十幾張表，很大概率，你這個(gè)是報(bào)表展示的需求，可以用etl工具抽取必要的字段，然后預(yù)處理一些簡(jiǎn)單匯總，這樣能少掃描記錄，提升查詢速度

建議三：

建議使用適合做數(shù)據(jù)分析的平臺(tái)，如Hadoop，hbase，tispark

什么業(yè)務(wù)需要關(guān)鍵這么多表檢索？用物化視圖做多次查詢，或先優(yōu)化一下腦子

這種查詢大概率不是要求查實(shí)時(shí)數(shù)據(jù)，就是統(tǒng)計(jì)報(bào)表用的，那你為什么非得要從原數(shù)據(jù)結(jié)構(gòu)上做這種復(fù)雜查詢？為什么不能去做etl之后再優(yōu)化數(shù)據(jù)結(jié)構(gòu)？一條路走到黑等著的就肯定是死胡同。如果是要求查詢實(shí)時(shí)數(shù)據(jù)，那就用業(yè)務(wù)代碼去簡(jiǎn)化查詢邏輯，用業(yè)務(wù)代碼做數(shù)據(jù)計(jì)算和拼接，把變動(dòng)頻率低的數(shù)據(jù)做緩存，把讀庫(kù)做分庫(kù)分表，辦法多的是，你除了寫sql就不會(huì)別的了？

一次查詢需要關(guān)聯(lián)十幾張表，是不是報(bào)表查詢的維度太多了？

關(guān)聯(lián)子查詢的執(zhí)行邏輯和通常的SELECT語(yǔ)句的執(zhí)行邏輯完成不一樣。這就是SQL關(guān)聯(lián)子查詢難以理解的原因。

在關(guān)聯(lián)查詢時(shí)要注意：where子句中一定要包含表之間的連接條件，如 line.lid=track.lid，否則查詢結(jié)果會(huì)完全超乎我們的想象，造成不必要的麻煩。
我看了一下回答，感覺(jué)很少有人能說(shuō)到點(diǎn)子上。

先說(shuō)說(shuō)需求吧，一次十幾張表，這是什么需求？是不是理解錯(cuò)誤，還是說(shuō)這需求必須要做？建議和業(yè)務(wù)溝通溝通。

如果說(shuō)，需求真的不能改，那就用視圖吧。

使用視圖時(shí)，會(huì)運(yùn)行視圖里的sql查詢語(yǔ)句創(chuàng)建出一張臨時(shí)表。

可以將頻繁使用的select語(yǔ)句保存成視圖，這樣就不用每次都重新書寫了。

使用視圖需要注意什么？

（1）避免在視圖的基礎(chǔ)上再次創(chuàng)建視圖，因?yàn)檫@樣多重視圖會(huì)降低sql的性能和效率；

（2）不能往視圖里插入數(shù)據(jù)，不然會(huì)報(bào)錯(cuò)。

最后，其實(shí)做報(bào)表真的不復(fù)雜，你要是用好報(bào)表工具FineReport，寫sql那真的是很輕松，回復(fù)“報(bào)表”就能有了。

互聯(lián)網(wǎng)時(shí)代倡導(dǎo)非關(guān)系型數(shù)據(jù)庫(kù)，首先保證單表查詢速度到極致，然后程序設(shè)計(jì)數(shù)據(jù)關(guān)聯(lián)最終算出結(jié)果，這才是解決之道。強(qiáng)烈依賴關(guān)系型數(shù)據(jù)庫(kù)是一種偷懶的方式，當(dāng)今海量數(shù)據(jù)時(shí)代，關(guān)系型數(shù)據(jù)庫(kù)用武之地也就剩下對(duì)速度要求不高的后臺(tái)統(tǒng)計(jì)和用戶量低的場(chǎng)景。

良好的設(shè)計(jì)數(shù)據(jù)庫(kù)，這種情況往往是糟糕的數(shù)據(jù)庫(kù)設(shè)計(jì)的問(wèn)題。找個(gè)對(duì)數(shù)據(jù)庫(kù)有深入了解大牛，幫忙規(guī)劃一下，要不了幾天，但很解決問(wèn)題。

本人寫sql也有好多年了，但一次查詢關(guān)聯(lián)10幾張表的情況還沒(méi)碰到過(guò)。但是這種情況還是有優(yōu)化的方法的。

首先查詢關(guān)聯(lián)10幾張表，不管是內(nèi)聯(lián)還是外聯(lián)，不管怎么優(yōu)化你的sql語(yǔ)句，比如建索引,指定返回列,where加限制條件，我相信你的結(jié)果還是會(huì)很慢的。 因?yàn)檫@已經(jīng)不是技術(shù)層面可以去優(yōu)化的，建議還是從業(yè)務(wù)層面去優(yōu)化。

不管多復(fù)雜的業(yè)務(wù)我們都可以去分解它，將它分解成一段段的子結(jié)果集，可以將它們作為臨時(shí)表或者結(jié)果表存儲(chǔ)起來(lái)，在最終的查詢時(shí)可以從分解的子集去查詢，這樣就避免了多表關(guān)聯(lián)，而且這樣代碼可讀性，可維護(hù)性更好。也符合我們?cè)O(shè)計(jì)代碼的基本原則。