數據庫運行很慢的原因分析

本篇內容介紹了“數據庫運行很慢的原因分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

當你發現數據庫查詢特別慢的時候，并且從硬件配置、SQL優化和索引等方面都找不出原因，那你可能需要從數據庫的計算引擎本身的性能找下原因。

數據庫的計算引擎性能有多重要？我們可以拿汽車做個簡單類比。服務器硬件配置是基礎設施，相當于汽車行駛的道路，高速公路和山村土路的行駛效果肯定是不一樣的；SQL的查詢優化相當于駕駛水平；而數據庫計算引擎就相當于汽車發動機，既是數據庫性能的源動力，也是各家廠商最核心的技術壁壘。

那么，我們就從數據庫計算引擎的實現技術探究下如何提高數據庫性能。下圖是從客戶端發出一條SQL語句到結果返回給客戶端的簡化流程。

如果把數據庫內核看成一個組織，那么優化器就位于組織的最上層，作為組織的首腦發號施令；執行器位于組織的中間，嚴格執行優化器下發的計劃，從存儲空間中讀取數據進行加工處理，最終返回給客戶端。

優化器

如何形象的理解優化器？以查詢“知乎點贊過萬的回答”為例，用戶通過SQL告訴數據庫“給我找出點贊過萬的回答”，優化器把用戶的需求轉換為“如何找到點贊過萬的回答”的策略和方法，即查詢計劃。

同一種SQL會有成千上萬種不同的執行計劃，而好的執行計劃和差的執行計劃在運行性能上會有天壤之別。

如何從成千上萬種查詢計劃中選出最優的？早期數據庫的查詢優化器通常采用啟發式規則進行優化RBP（Rule Based Optimization），這種優化方式不夠準確，往往難以獲得最優的執行計劃，而基于代價的優化CBO (Cost Based Optimization)則能夠針對大多數場景高效篩選出性能最好的執行計劃。

因此，我們見到的高性能數據庫引擎往往使用基于代價的優化器。

執行器

執行器是數據庫內核最重要的部件之一。提升執行器的性能，會很大程度上提升數據庫性能，因此各大數據庫廠商都紛紛投入很多精力到執行器技術的研發中。

提升執行器性能的手段主要有兩種技術路線，一種是向量計算（vectorized execution），另外一種是代碼生成（code generation）。目前主流的數據庫廠商會使用其中一種執行器優化技術，例如Snowflake使用的是向量計算，Impala使用的是代碼生成, Spark兩種都有使用，OushuDB使用了向量計算外加SIMD優化技術。而一些傳統的數據庫還未實現其中任何一種性能技術。

聰明的你可能要問了，哪種技術路線更勝一籌？關于這個問題，不少研究和論文給出了答案：兩種技術側重點不同但都可以提升性能，不同的語句也會有不同程度的性能提升，向量計算更適合并行處理數據SIMD。所以，想要在并行計算的基礎上進一步提升數據庫引擎性能，就可以結合并行處理數據充分利用CPU硬件指令（比如SIMD）。

SIMD

SIMD(single instruction multi-data), 即單指令多數據流，以同步的方式在同一時間內執行同一條指令。相比單指令單數據流（SISD），單指令多數據流一次性獲得所有操作數進而加快了運算，特別是數據密集型運算。

如上圖所示，使用標量運算一次只能執行一對數據的乘法操作，而采用SIMD乘法指令則可以一次同時執行四對數據的乘法操作。作為向量體系結構的一種，SIMD使用一條向量指令開啟一組數據操作，其中數據的加載、存儲以及數據計算以流水線的形式進行。

通過在國際標準數據集TPCH上的測試，我們發現OushuDB 4.x的速度比最新版本的SparkSQL 3.x快大約一個數量級。

基于以上的分析，如果從提升數據庫性能的角度，我們可以采用基于代價的優化+向量計算+ SIMD的技術路徑，作為提升數據庫性能的首選方法。

“數據庫運行很慢的原因分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！