一、前言
是一個用于聯機分析(OLAP)的列式數據庫管理系統(DBMS)；目前我們使用CH作為實時數倉用于統計分析，在做性能優化的時候使用了 物化視圖 這一特性作為優化手段，本文主要分享物化視圖的特性與如何使用它來優化的查詢性能。
二、概念
數據庫中的 視圖(View) 指的是通過一張或多張表查詢出來的 邏輯表 ，本身只是一段 SQL 的封裝并 不存儲數據。
而 物化視圖( View) 與普通視圖不同的地方在于它是一個查詢結果的數據庫對象(持久化存儲)，非常趨近于表；物化視圖是數據庫中的預計算邏輯+顯式緩存，典型的空間換時間思路，所以用得好的話，它可以避免對基礎表的頻繁查詢并復用結果，從而顯著提升查詢的性能。
在傳統關系型數據庫中，、、SQL 等都支持物化視圖可更新的物化視圖，而作為MPP數據庫的也支持該特性。
三、物化視圖
中的物化視圖可以掛接在任意引擎的基礎表上，而且會自動更新數據，它可以借助 家族引擎(、等)，得到一個實時的預聚合，滿足快速查詢；但是對 更新 與 刪除 操作支持并不好，更像是個插入觸發器。
創建語法：
CREATE [MATERIALIZED] VIEW [IF NOT EXISTS] [db.]table_name [TO[db.]name] [ENGINE = engine] [POPULATE] AS SELECT ...關鍵字決定了物化視圖的更新策略：
官方并不推薦使用，因為在創建視圖過程中插入表中的數據并不會寫入視圖，會造成數據的丟失。
四、案例4.1. 場景
假設有一個日志表 來記錄每次登錄的用戶信息，現在需要按用戶所屬地為維度來統計每天的登錄次數。
PS：這種 只有新增記錄，沒有更新刪除的記錄表就非常適合使用 物化視圖 來優化統計性能
正常的聚合SQL如下：city為用戶所屬地，為登錄時間
select city, login_date, count(1) login_cnt
from login_user_log
group by city, login_date增加 物化視圖 后的架構如下圖所示：
4.2. 建表
創建基礎表：基礎表使用 引擎，進行預聚合處理
CREATE TABLE login_user_log_base
(
city String,
login_date Date,
login_cnt UInt32
)
ENGINE = SummingMergeTree()
ORDER BY (city, login_date)表引擎主要用于只關心聚合后的數據可更新的物化視圖，而不關心明細數據的場景，它能夠在合并分區的時候按照預先定義的條件聚合匯總數據，將同一分組下的多行數據匯總到一行，可以顯著的 減少存儲空間并加快數據查詢的速度。
創建物化視圖：用戶在創建物化視圖時，通過 AS ... 子句從源表中查詢需要的列，十分靈活
CREATE MATERIALIZED VIEW if not exists login_user_log_mv
TO login_user_log_base
AS
SELECT city, login_date, count(1) login_cnt
from login_user_log
group by city, login_date使用 TO 關鍵字關聯 物化視圖 與 基礎表，需要自己初始化歷史數據。
4.3. 查詢統計結果
使用物化視圖查詢
SELECT city, login_date, sum(login_cnt) cnt
from login_user_log_mv
group by city, login_date注意：在使用物化視圖（引擎）的時候，也需要按照聚合查詢來寫sql，因為雖然 會自己預聚合，但是并不是實時的，具體執行聚合的時機并 不可控。
總結在創建 MV 表時，一定要使用 TO 關鍵字為 MV 表指定存儲位置，否則不支持 嵌套視圖(多個物化視圖繼續聚合一個新的視圖)在創建 MV 表時如果用到了多表聯查，不能為連接表指定別名，如果多個連接表中存在同名字段，在連接表的查詢語句中使用 AS 將字段名區分開在創建 MV 表時如果用到了多表聯查，只有當第一個查詢的表有數據插入時，這個 MV 才會被觸發在創建 MV 表時不要使用 關鍵字，而是在 MV 表建好之后將數據手動導入 MV 表在使用 MV 的聚合引擎時，也需要按照聚合查詢來寫sql，因為聚合時機不可控