SQL語句執行很慢？快來康康GaussDB(for MySQL)推出的這個小功能
在MySQL數據庫中，SQL語句的執行大體分爲解析、優化、執行幾個主要的階段。其中優化階段會生成執行計劃，執行階段根據執行計劃執行語句，返回結果。優化階段要經歷邏輯優化、物理優化等步驟，會消耗大量時間。
爲提升SQL語句執行效率，華爲雲GaussDB(for MySQL)推出了Plan Cache功能，該功能對執行計劃進行緩存，當相同的SQL語句多次執行時，可跳過優化階段，直接進入執行階段，從而提高SQL語句的執行速度。
1.原生MySQL VS GaussDB(for MySQL)
爲了讓大家有更直觀的感受，我們對比了原生MySQL與GaussDB(for MySQL)的SQL語句執行場景，大家可以通過對比感知Plan Cache功能的妙處。
●未使用Plan Cache功能的原生MySQL prepare 語句主要執行流程如下：
（1）parser階段生成解析樹，存放在stmt mem內存區域。
（2）optimize階段對解析樹進行查詢優化，並生成執行計劃（迭代器）。
（3）execute階段根據執行計劃，執行查詢，返回查詢結果。
（4）cleanup階段對執行過程中生成的一些對象進行清理。
其中步驟1只有第一次執行查詢時，需要執行。以後每次執行，使用保存在stmt mem區域中的解析樹即可。
然而步驟2，每次執行時，都需要重新執行一遍，主要原因如下：
Ø 迭代器是根據optimize階段生成的join、qeb_tab等對象產生的。在每次語句執行完成後，cleanup階段會對其中一些對象進行清理。
Ø 這些對象的存儲空間是從runtime mem內存區域分配的，每次語句執行完成後，會釋放runtime mem內存。
●啓用Plan Cache後的GaussDB(for MySQL) prepare 語句主要執行流程如下：
（1）當查詢第一次執行時，系統檢查語句是否滿足執行計劃緩存的條件，並設置對應的狀態標籤。
（2）當查詢第二次執行時，如果執行計劃可以被緩存，則執行如下操作：
Ø 修改join、qep_tab等對象（生成迭代器時必需的對象）的存儲分配策略，從stmt mem內存區域分配空間。
Ø Cleanup階段進行部分清理，join、qep_tab等對象被保留，這樣下一次執行時可重用。
（3）當語句第三次執行時，如果執行計劃已被緩存，則跳過optimize階段，直接進入execute階段。
2.Plan Cache功能的參數替換與配置
因爲執行計劃（迭代器）中包含條件數據，所以每次執行時，需要替換緩存的執行計劃參數，否則查詢結果保持不變（爲執行緩存時結果）。如下所示：
Const
Range
參數配置方面：
Ø plan_cache: on/off 開啓/關閉執行計劃緩存功能；
Ø Cached_prepared_stmt_count: 監控已緩存的執行計劃數。
3.Plan Cache性能測試
TPCC測試下數據明細：
Feature |
BMSQLBase tpmC |
BMSQLIncr. tpmC |
Plan cache off |
582967.16 |
|
Plan cache on |
664607.06 |
81639.9 |
測試結果：性能提升14% |
sysbench:
oltp_point_select 20%
通過對比測試，我們得知在開啓Plan Cache功能的情況下，TPCC、sysbench point select場景分別有14%和20%的性能提升。
相比原生MySQL，在有大量相同查詢語句的場景下，Plan Cache可以有效減少語句的優化時間，提升查詢性能。目前，GaussDB(for MySQL) 執行計劃緩存爲會話級（會消耗額外的內存空間），支持場景爲Prepare語句的單表查詢、更新，未來會不斷技術創新支持更多的場景，進行更多的改善和優化。
GaussDB(for MySQL)是華爲雲數據庫重點打造的雲原生數據庫之一，除了Plan Cache功能，還基於存算分離架構，提供了跨AZ部署、極致擴展、一寫多讀，算子下推等雲原生能力。如果您想要了解更多，可以回看華爲雲GaussDB在“華爲雲TechWave雲原生2.0技術峯會”的精彩內容。
▼點擊“閱讀原文”，回看精彩內容