在某些情境中，可能會出現無法高效利用主鍵索引的查詢。這些情況下，ClickHouse可能需要對每個列執行全表掃描，尤其是在應用WHERE子句條件時。您可使用跳數索引（data skipping index），以加速這些查詢。
瞭解跳數索引
跳數索引使用了特定的資料結構，其核心機制如下：
功能目標：通過data part 的 granule（即預先產生的標記），跳過不符合
WHERE子句條件的data part，減少 IO 和計算量。實現方式：在
data part的granule建立輕量級索引，快速判斷data part是否包含目標資料。適用情境：主鍵無法覆蓋的列過濾、複雜運算式查詢的情境。
更多跳數索引詳情，請參見Use data skipping indices where appropriate。
過度使用影響
在某些情況下，跳數索引能夠加速特定查詢的速度，但在許多情況下，因過度使用它而產生負面影響。
效能未提升反而降低。
寫入開銷增加：索引構建增加寫入延遲，降低資料輸送量。
查詢效率降低：若索引列與主鍵無統計相關性，大量data part仍被載入評估，導致系統會進行索引檢查和全表掃描，導致雙重開銷。
表設計複雜化。
表結構臃腫：多個索引增加中繼資料管理複雜度，影響維護與可讀性。
維護成本：索引需隨資料分布變化動態調整，否則可能失效。
使用原則
使用跳數索引時，不是簡單的建立索引，而是需要仔細設計才能發揮最大作用。因此，我們經常看到它們使表設計複雜化，並減慢插入效能，而很少（如果有的話）提高查詢效能。以下為跳數索引的一些使用原則。
使用優先順序黃金法則
主鍵最佳化先行：確保主鍵覆蓋高頻查詢（建議主鍵列 ≤ 4-5 個）。主鍵最佳實務，請參見主鍵設計最佳實務。
次選預計算方案：使用 投影（Projections）或 物化視圖預彙總高頻查詢資料。
最後考慮使用跳數索引。
設計原則
強相關性要求：索引列必須與主鍵有明確統計關聯（如時序情境的時間戳記與裝置ID）。
高篩選率驗證：索引需能跳過90%以上的資料區塊方有意義，否則性價比為負。
實施建議
分析驗證：引入索引後，通過查詢日誌與
EXPLAIN分析實際跳過量。動態調整：定期評估索引有效性，隨資料分布變化及時最佳化或刪除。
更多跳數索引的最佳實務，請參見跳數索引最佳實務。