1 查詢性能優化的意義
對一個資料庫産品來說：
- 性能提升 10 倍：使用者的機器資源可以從100台減少到10台
- 從 10 秒 到1秒: 互動式分析體驗, 讓之前不可能上線的應用變得可能
- 敲門磚：産品 POC 幾乎不會缺少的環節，因為查詢性能相對比較容易量化
對一個資料庫工程師來說：
- 當一個優化有好幾倍甚至是數量級的提升時，會有很大的成就感
- 專業能力的快速提升，因為資料庫的性能優化是一個多元度，很複雜的系統工程，從架構到細節，從硬體到軟體，從核心到應用，幾乎都會有涉及
2 查詢性能優化的目标
從應用視角，主要是 Latency 和 Throughput。（在總資源不變的情況下 縮短響應時間，一般都可以提升吞吐率。）
從系統資源的視角，我們要優化 CPU, IO, Memory, NetWork 等系統資源的使用率。(在性能優化的過程中，我們在關注查詢吞吐和時延的同時，也一定要關注系統資源的使用率。因為有時候的性能提升幾倍的同時，也多用了幾倍的 CPU)
3 如何發現性能瓶頸點
一方面可以通過資料庫系統内置的性能優化工具或者可觀測性工具去找到瓶頸點，另一方面可以通過 Linux 通用的性能測試工具來尋找瓶頸點。
3.1 StarRocks Observability : Query Profile
如上圖所示，查詢 Profile 是我們發現性能瓶頸點最常用的工具，從 Profile， 我們可以知道一個查詢是慢在 plan 階段，還是執行階段，也能知道是哪個算子是執行瓶頸
3.2 StarRocks Observability : Optimizer Trace
如上圖所示，我們通過一個指令就可以知道 StarRocks 優化器到底慢在哪一個階段，可以快速定位出優化器階段的性能瓶頸。
3.3 StarRocks Observability : Executor Trace
如上圖所示，我們可以通過 StarRocks 的執行器的 trace 工具快速定位出執行層到底是慢在哪個點，比如是CPU的問題，IO的問題，還是排程架構的問題。
3.4 CPU Sampling —— Perf
除了資料庫系統自身的工具，我們也可以使用 Linux 通用的性能 profile 工具，比如，最常見的性能 Profile 工具，Perf，可以通過火焰圖看成 CPU 熱點。詳情大家可以參考：https://www.brendangregg.com/perf.html
3.5 Off CPU Tracing —— eBPF
很多時候，性能的瓶頸并不是在 CPU 執行本身，而是在 IO，網絡，Lock 上，這時候我們就需要進行 Off CPU 分析，而且這時候基于 Sampling 的性能工具往往沒有效果，我們需要使用基于 Trace 的 性能工具，比如 eBPF。詳情大家可以參考 https://www.brendangregg.com/offcpuanalysis.html
3.6 Intel 的 Top-down 分析方法
如上圖所示，Intel 基于 CPU 執行的整個過程，提出了 《Top-down Microarchitecture Analysis Method》的 CPU 微架構性能分析方法，将 CPU 執行的可能瓶頸點分為4大類，然後每一類在不斷細分，層層深入，定位到最具體的性能瓶頸點。
為了便于大家了解，我們可以将上圖簡化為下圖（不完全準确）：
即影響一個 CPU 程式的性能瓶頸主要有4大點：Retiring、Bad Speculation、Frontend Bound 和 Backend Bound，4個瓶頸點導緻的主要原因（不完全準确）依次是：缺乏 SIMD 指令優化，分支預測錯誤，指令 Cache Miss， 資料 Cache Miss。
3.7 Linux Performance tools
如上圖所示，作業系統每個子產品的問題都有對應的工具可以進行分析，大家在日常工作中就需要不斷積累，清楚哪類問題可以用哪些工具解決，也要清楚每個重要工具可以解決哪些問題。
3.8 性能監控名額
這一點上 TIDB 做的比較好，整個查詢過程的關鍵性能名額都暴露出來，可以比較友善的分析某類問題的性能瓶頸，主要是對DBA，解決方案，普通使用者更加友好。詳情可以參考 https://docs.pingcap.com/tidb/dev/performance-tuning-methods
3.9 優化器 Plan Test
SQL 是聲明式，隻告訴了 What，沒有告訴 How, 是以一個 SQL 的執行路徑可能成千上萬，優化器選擇出的最終 Plan 往往不是最優的，我們研發有時候也不能判斷哪種執行計劃是最優的。主要是兩個原因：1是執行計劃很多，人很難枚舉，2是執行計劃的真實執行性能是和執行器每個算子的性能，叢集規模，資料特點，硬體資源等都有關系。是以我們需要有專門的優化器 Plan 測試工具去枚舉測試 不同執行計劃的真實性能，進而發現更優的執行計劃。
如上圖所示，上面兩個SQL 等價，但是很多資料庫的對于第二個SQL 卻無法推斷出 ename not like 'ACCT' 這個謂詞, 導緻有3倍的性能差距。
下面兩個 SQL，如果有 emp_pk 是主鍵的資訊，group by emp_pk 也可以直接優化掉，性能就可以提升3倍。
4 如何進行查詢性能優化
4.1 CPU 通用性能優化
如上圖所示，資料庫也是一個大型的 CPU 應用，是以我們可以先按照所有 CPU 應用的通用優化思路去優化資料庫的查詢性能，比如自底向上我們依次可以從這些點進行優化：
- 硬體：首先是直接替換硬體，比如從機械硬碟替換為 NVME，SSB，另一方面，為了充分發揮新硬體的性能優勢，我們往往需要在系統架構，資料結構和算法層面針對新硬體進行優化
- 作業系統：作業系統的核心更新往往會給我們帶來大量新功能和性能優化，比如 io_uring 異步 IO 接口
- 編譯器：編譯器持續在優化性能，往往低版本不能自動向量化的代碼，在高版本就可以自動向量化了
- 程式設計語言和第三方庫：首先是程式設計語言本身的性能差距，其次是在同樣的程式設計語言下，也有大量的性能優化技巧，這個我之後會專門再寫篇文章
- 應用的架構：應用的架構會直接影響可擴充性，對性能的影響會很大，比如 MPP VS Scatter-Gather
- 資料結構和算法：不同的資料結構和算法往往會有量級的性能差距，這個大家都深有體會，比如 hashtable, 這個資料結構，工業界幾十年一直在持續優化。
- Low Level的優化：比如 SIMD 和 CPU Cache
- 業務邏輯的優化：比如從精确去重變為近似去重，比如資料模組化的優化
4.2 DataBase Pre Process VS Runtime Process
這一點我在 如何打造一款極速分析型資料庫 已經解釋的比較清楚。
4.3 DataBase High Level Optimization
具體到資料庫層面的優化，我們可以分為 High Level 和 Low Level 的兩大類優化。High Level 的優化主要包括：
- 架構：比如是存儲分離還是存算一體，比如 ServerLess，比如是分布式 Cache 還是 Local Cache
- 多機 Scale Out 的能力 ：查詢能不能充分利用多機的資源，查詢性能 能不能随着節點 Scale Out 成比例提升
- 多核 Scale Up 的能力：查詢能不能充分利用多核的資源，查詢性能 能不能随着核數 Scale Up 成比例提升
- 執行政策：比如聚合，Join 是 Sort Based，還是 Hash Based，比如 CTE Reused，比如聚合下推
- 執行模型：比如是否支援向量化，是否支援 Code gen，是Push 還是 Pull 等
4.4 DataBase Low Level Optimization
這一點大家可以參考我之前在 StarRocks 技術内幕：向量化程式設計精髓 的分享，之後的每一個點我也會在 OLAP 性能優化指南 詳細展開描述
4.5 從資源的角度進行優化
性能優化的本質就是優化各種系統資源的使用。我們針對查詢優化的各種手段，其實本質上都是在優化 CPU, 記憶體，IO，網絡等系統資源的使用:
- 存儲層的 Read Data Less And Fast 其實是在優化 IO 資源
- 計算層的 Transfer Data Less And Fast 其實是在優化網絡資源
- 計算層的 Process Data Less And Fast 其實是在優化 CPU 和 記憶體資源
如果我們解決一個問題的算法複雜度相同，那麼誰的實作更優，就是看誰做的無用功更少，使用的系統資源更少。
上圖就是一個查詢執行層優化網絡的各種優化手段的示例。
5 如何做好性能測試
- 對比測試：硬體環境，資料，模組化等基礎資訊對齊 (出過很多次問題)
- 不同硬體 (核數多少，磁盤媒體，出過多次問題)
- 不能隻關注單并發，還要關注高并發
- 不能隻關注延遲和吞吐，還要關注資源使用率
- 不能隻關注 AVG，還要關注PT99和抖動
- 不能隻關注目标場景，各種典型 Workload 的查詢都要測試
- 細緻，周密，敏銳，自動化，标準化
6 CPU 架構下的資料庫性能優化有盡頭嗎？
答案是 性能優化永無止境 ，因為
- 硬體在持續變化：底層硬體的變動可能直接導緻上層軟體的架構革新或者是資料結構和算法層面的革新
- 資料庫架構在持續變化：架構的變化會可能導緻我們的執行政策，執行模型，優化重點都發生變化
- 更多的上下文，更多的優化政策：隻要有更多的上下文，更多的資訊，我們就可以實作針對性的優化
- 資料結構和算法層面的創新：資料結構和算法層面的創新是永遠不會停止的，一個簡單的 Hash 表 工業界都從來沒有停止優化
- 執行政策層面的創新：比如 CTE 複用，聚合下推，各類 Runtime Filter
- From Manually To Adaptive：在未來，我們必然會向使用者屏蔽掉各種配置，各種 Session 變量，而每去掉一個配置，就可能意味着我們會多一種自适應執行的政策
7 生産環境的性能 VS Benchmark 的性能
很多時候，我們的性能測試都是在标準環境進行，都盡可能屏蔽噪音，但是在生産環境，要想取得在 Benchmark 中的性能資料，我們可能還要再付出10倍不止的精力：
- 大查詢影響小查詢
- 導入，查詢，Compaction，統計資訊等任務互相影響
- 并發控制 & 查詢排隊
- 查詢逾時 & Retry
- PT99, Not Avg
- 慢節點
- 資料傾斜
在生産環境中，上面的每一個問題都不是很好解決，都是一個大型的優化項目。
8 性能優化的權衡
在考慮要不要進行一個性能優化時，我們還需要從下面幾點進行權衡：
- 代碼複雜度
- 相容性
- 穩定性
- 優化的投入産出比
- 優化的通用性
- 性能的可預測性
我們永遠都要有這樣一個意識：
- 不是所有的需求都要滿足
- 不是所有的Bug都要修複
- 不是所有的優化都要實作
9 OLAP 資料庫性能優化的未來
1 Serverless 架構下面向成本的性能優化：
參考 如何打造一款極速分析型資料庫：ServerLess 之極緻彈性 要想在 Serverless 架構下取得很好的性能，我們的整個架構，執行架構，算法實作上就不能單點和串行，必須保證每個S QL 都可以随着節點數增多性能可以獲得成比例提升，其次，我們也必須解決資料傾斜問題，否則，就無法充分利用整個叢集的資源。
2 真實業務場景的自适應執行優化：
基于不同的資料分布，資料技術，資料基數，資料相關性，優化器很難保證任何時候都産生比較好的plan，是以自适應執行的優化不可避免，可以參考 資料庫之美 —— 查詢自适應執行
3 真實曆史資料的 AI 優化
- 在批處理場景下，我們可以基于曆史運作任務的資訊去進行 History Base 的優化
- 我們可以根據使用者真實執行SQL的各種名額資料，結合機器學習，進行自動推薦物化視圖，自動 clusting，優化執行計劃等等
10 如何成長為資料庫性能優化專家
- CPU & 記憶體 & 網絡 & IO 的專業知識 (原理，性能名額，性能工具)
- 資料庫領域的專業知識
- 性能測試的工具和方法論
- 資料庫領域各種優化思路，
- 關注學術和工業界的進展
- 關注新硬體，新架構
- 目标系統原理，源碼的深刻了解和掌握
性能優化是一門工程，實踐出真知，大家還是多動手，多嘗試，多積累經驗。