為什么我們的系統(tǒng)里經(jīng)常需要寫各種復(fù)雜SQL？

1. 由于系統(tǒng)中的表設(shè)計問題，導(dǎo)致需要查詢一些數(shù)據(jù)的時候，不得不通過多表關(guān)聯(lián)實現(xiàn)數(shù)據(jù)的組合才能滿足業(yè)務(wù)。

1. 例如數(shù)據(jù)庫前期的設(shè)計不合理，導(dǎo)致的只能通過復(fù)雜查詢才能滿足。

2. 需求的變化，導(dǎo)致數(shù)據(jù)庫的設(shè)計不合理，從而不得不通過更加復(fù)雜的查詢滿足業(yè)務(wù)。

2. 統(tǒng)計、查詢等需求的變化，導(dǎo)致為了滿足查詢的需求不得不通過復(fù)雜查詢才能夠完成數(shù)據(jù)的匹配。

1. 由于需求的變化導(dǎo)致不得不通過更多的數(shù)據(jù)關(guān)聯(lián)才能滿足業(yè)務(wù)場景。

2. 數(shù)據(jù)挖掘?qū)用娴男枨?，由于對查詢的顆粒度要求非常細(xì)致，只能通過各種條件檢索才能滿足業(yè)務(wù)場景。

3. 由于對系統(tǒng)的數(shù)據(jù)庫設(shè)計不夠了解，然后自己編寫了一些不是特別合理，但卻特別復(fù)雜的SQL以滿足查詢業(yè)務(wù)。

面對復(fù)雜SQL性能問題，我們可以選擇的解決方式：

1. 對SQL做性能優(yōu)化

2. 對數(shù)據(jù)庫做優(yōu)化，例如數(shù)據(jù)庫讀寫分離、分庫、分表、更換高性能數(shù)據(jù)庫等方式。

3. 系統(tǒng)設(shè)計上的優(yōu)化，例如建立寬表，或者將數(shù)據(jù)同步到緩存數(shù)據(jù)庫或搜索引擎數(shù)據(jù)庫等方式

對于上述解決方案，又帶來了的新問題：

1. 對于SQL性能的優(yōu)化，通常需求對系統(tǒng)的數(shù)據(jù)庫設(shè)計比較清楚，不然很難實現(xiàn)優(yōu)化。而且業(yè)務(wù)不斷的變化，這樣的持續(xù)SQL層面的優(yōu)化，也變得難以滿足需求，即要查詢到數(shù)據(jù)，還要保證查詢性能，通常是魚與熊掌不可兼得的事情。

2. 通常對數(shù)據(jù)庫層面的優(yōu)化會牽連系統(tǒng)，而且數(shù)據(jù)庫層面的優(yōu)化，也會隨著后續(xù)業(yè)務(wù)的復(fù)雜變得不斷的優(yōu)化，成了一個無底洞。而且數(shù)據(jù)庫層面的優(yōu)化對技術(shù)的門檻要求非常高，這將也是一個非常難以落地的方案。

3. 系統(tǒng)設(shè)計上的優(yōu)化，必然會對當(dāng)前的系統(tǒng)做調(diào)整。假如將檢索數(shù)據(jù)同步到緩存或搜索引擎以后，雖然系統(tǒng)的查詢效率上來了，但是卻帶來了一個新的問題，數(shù)據(jù)同步問題。數(shù)據(jù)何時同步，緩存何時清理，這些問題又稱為新的困擾。

總結(jié)

?這個問題的根是數(shù)據(jù)的靈活性不夠，數(shù)據(jù)要做好兩個職責(zé)：

1. 數(shù)據(jù)要維護業(yè)務(wù)的完整性。

2. 數(shù)據(jù)要滿足查詢場景的多樣性。

? ? 如果數(shù)據(jù)本身是業(yè)務(wù)模型，那么數(shù)據(jù)就難以滿足查詢場景的多樣性，因此我們不能將數(shù)據(jù)作為業(yè)務(wù)模型，要將業(yè)務(wù)模型從數(shù)據(jù)庫模型改為業(yè)務(wù)模型，將數(shù)據(jù)與業(yè)務(wù)分離，實現(xiàn)數(shù)據(jù)的維護與業(yè)務(wù)分離，這樣可以讓數(shù)據(jù)更好的滿是上述的兩個職責(zé)，利用事件機制與消息隊列實現(xiàn)模型與數(shù)據(jù)的同步，實現(xiàn)數(shù)據(jù)根據(jù)事件消息，完成實時數(shù)據(jù)的適配與維護。