為什麼需要查詢優化？#

ClickHouse 的確擅長處理數十億筆資料，但這並不代表我們可以「無腦查詢」。隨著資料量從 100 萬 → 1000 萬 → 1 億 成長，若沒有妥善設計，查詢速度可能會從毫秒級惡化成數秒甚至數十秒，直接影響使用者體驗。

舉例來說：

• Dashboard 無法即時更新，導致決策延遲
• API 響應超過數秒，造成前端操作卡頓
• Backend, Data Scientist 無法在合適時間內完成查詢分析

因此，查詢優化不只是為了「快」，更是為了系統的穩定性與可擴展性。

OFFSET 分頁效能差#

在許多系統中，最常見的需求就是「分頁查詢」。假設我們有一個 events 表，用來紀錄使用者的行為事件：

1
SELECT * FROM events
2
ORDER BY created_at DESC
3
LIMIT 50 OFFSET 1000000;

這個查詢看似正常，但隨著 OFFSET 變大，效能會急速下降。原因在於 ClickHouse 需要掃描並丟棄前面一百萬筆資料，才能回傳第 1000001 筆到 1000050 筆。

1
SELECT * FROM events
2
WHERE created_at < '2025-01-01 00:00:00'
3
ORDER BY created_at DESC
4
LIMIT 50;

WHERE 條件未使用索引#

另一個常見問題是「查詢條件沒有命中索引」。假設我們要查詢某個使用者最近 7 天的紀錄：

1
SELECT COUNT(*)
2
FROM logs
3
WHERE user_id = 123
4
AND created_at >= today() - 7;

如果表的排序鍵不是 (user_id, created_at)，這個查詢就會全表掃描，效能極差。

1
CREATE TABLE logs
2
(
3
    user_id UInt64,
4
    created_at DateTime,
5
    event_type String,
6
    ...
7
)
8
ENGINE = MergeTree()
9
PARTITION BY toYYYYMM(created_at)
10
ORDER BY (user_id, created_at);

重複資料導致彙總變慢#

在實務上，我們常會遇到「批次匯入導致重複資料」的情境。例如，某些 ETL 程序每天匯入一份全量資料，但會包含重複紀錄。

原始查詢需要先 GROUP BY 去重，這對數億筆資料來說效能極差。

1
CREATE TABLE events
2
(
3
    id UInt64,
4
    user_id UInt64,
5
    event_type String,
6
    version UInt32
7
)
8
ENGINE = ReplacingMergeTree(version)
9
ORDER BY (id);

1
CREATE MATERIALIZED VIEW events_mv
2
ENGINE = SummingMergeTree()
3
ORDER BY (user_id, event_type)
4
AS
5
SELECT user_id, event_type, count() AS cnt
6
FROM events
7
GROUP BY user_id, event_type;

JOIN 效能不佳#

ClickHouse 的 JOIN 並不像傳統關聯式資料庫那樣靈活，若不小心，效能會很差。

假設我們要將 events 表與 users 表做關聯：

1
SELECT e.*, u.name
2
FROM events e
3
JOIN users u ON e.user_id = u.id;

若 users 是一張大表，JOIN 效能會急速下降。

1
CREATE DICTIONARY users_dict
2
(
3
    id UInt64,
4
    name String
5
)
6
PRIMARY KEY id
7
SOURCE(CLICKHOUSE(TABLE users))
8
LAYOUT(HASHED());

1
SELECT e.*, dictGet('users_dict', 'name', toUInt64(e.user_id)) AS user_name
2
FROM events e;

總結#

從這些案例可以看到，ClickHouse 的查詢效能優化大致遵循以下原則：

1. 避免 OFFSET，改用 Keyset 分頁
2. 設計良好的排序鍵與分區，讓查詢能命中索引
3. 使用 MergeTree 變種 (Replacing / Summing) 來處理去重與聚合
4. 善用 Materialized View 預先計算，避免重複運算
5. JOIN 最小化：小表 JOIN 可以轉成 Dictionary，大表 JOIN 需慎用
6. 盡量減少需要掃描的資料量，而不是「事後再過濾」

透過查詢優化，我們能將原本數秒甚至數十秒的查詢縮短到毫秒級，這對即時分析、線上系統效能都有關鍵意義。

希望這些案例能幫助大家在實務中更好地駕馭 ClickHouse！ 🚀