內置的數據無法實現高性能

這里說的“內”， 是指數據庫之內。

當數據量變大時，我們常常會感到數據庫的性能下降明顯，但是，無論怎樣優化 SQL(存儲過程)都仍然與根據數據量和運算復雜度計算出來的理論性能相差甚遠。這主要由如下幾方面原因造成：

1. SQL 限制與優化困難

我們已經多次說過，由于關系代數和 SQL 語法的限制，有許多高效的算法無法實施，比如前面說過的遍歷復用技術，以及去年談過的 JOIN 優化方法。使用 SQL 實現這類運算時，只能采用復雜度更高的方法，冗余的數據訪問量和計算量非常大，而且也很難利用多 CPU 進行并行計算。

SQL 不提倡分步計算，經常一條語句寫出幾百行、嵌套很多層。不分步的長語句很難利用某個子句的計算結果，常常帶來不必要的重復計算。而且過于復雜的也會給數據庫優化引擎造成負擔，優化引擎不能很好地理解運算邏輯而設計出最優的執行路徑。我們常常發現一條語句的幾個子部分執行都很快，結果集也不大，但合起來寫到一句 SQL 中就會很慢。

2. 存儲過程性能差

對于復雜的多步驟計算，我們常常要編寫存儲過程才能實現。而和 SQL 相比，存儲過程的取數遍歷過程要慢得多。同一個表的數據，使用存儲過程先 FETCH 出來再做聚合，要比直接用 SQL 聚合的性能慢出幾倍到十幾倍，本來這兩者的運算性能應當是差不多的(計算復雜度與數據訪問量都一樣)。有些針對明細數據的復雜處理只能把數據一條條取出才能實現時，這個性能就沒辦法得到保證了。

在存儲過程中，為了利用前面計算出來的中間結果，只要涉及集合性數據一般都要使用臨時表。而建表寫數的動作也是非常慢的，數據庫有太多約束性要求，而且常常需要把臨時表落地到外存。

3. 直接外部計算不現實

如果我們不采用 SQL，而將數據讀出后在庫外計算，是否可以提高性能呢？

大多數情況仍然不可以。一方面原因是數據庫 IO 性能大都很差，從數據庫中取數，要比從文件系統中讀數的性能差出一個數據量，經常發生取數時間遠遠超過計算時間的現象。

而且，有些高效算法會要求有特殊的存儲格式，比如需要事先將數據排序存儲，從而可以采用分段定位查找或實現有序歸并算法，而基于無序集合的 SQL 在理論上就無法支持，必須先排序才能保證取出數據的有序性，結果排序時間會超過計算本身。再比如行存或列存的選擇，一般數據庫只會采用一種(支持 OLTP 用行存且不壓縮，面向 OLAP 用列存并壓縮)，但使用行存還是列存需要由計算目標決定，在遍歷式計算采用列存較為合適，而使用索引定位查找時則更適合用行存。有時為了性能還可能把同一份數據存儲冗余的多份以面向不同用途，而在數據庫中很難有這么靈活的處理方式。

---

解決辦法，就是數據外置，具體說就是把數據搬出數據庫。使用合理的存儲方案再配以適用的算法，對于許多幾百上千行的存儲過程，經過這樣的改造后，性能常常都有幾倍的增長。

當然，這又會帶來新的問題。主要有三個方面：一是可管理性，在數據庫中有統一的數據視圖和約束性檢查，而外部文件系統則沒有這些東西；二是安全性，數據庫是個封閉體系，獲取數據的接口很單一，總有帳號認證的過程，而文件系統也沒有這些東西；三是數據更新能力，數據在不斷地變化中，數據庫有完整的數據更新功能，文件系統這方面卻很弱，一般只能做追加，還很難保證追加過程中的一致性(中途出錯時恢復)。

目前階段這個事還是需要權衡，獲得了數據庫的方便性就得不到高性能，要數據外置的高性能就要犧牲方便性。不過，隨著技術的進步，在文件系統上加強可管理性、安全性以及可更新能力又不犧牲或很少犧牲其性能，還是有可能做到的，數據庫的封閉性總要被打破。

總結

以上是生活随笔為你收集整理的join 高性能_内置的数据无法实现高性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。