從官網的Demo開始。官網給的介紹案例是以(CounterID、Date)這2個鍵來建立索引，可以看到壹對的(CounterID、Date)間隔地生成了壹個Marks，例如(a,1),(a,2)；根據Marks又生成了相應的Marks numbers。那麽"8192"這個index_granularity參數又是用來做什麽的呢？大家可以看下(a,1),(a,2)這2個索引之間，間隔了好幾個數據，即：
（1）index_granularity這個參數規定了數據按照索引規定排序以後，間隔多少行會建立壹個索引的Marks，即索引值
（2）稀疏索引的意義即是Clickhouse不對所以的列都建立索引（相比較Mysql的B樹索引會為每行都建立），而是間隔index_granularity列才建立壹個。
（3）Marks與Marks number均被保存在內存中，利於查詢的時候快速檢索。
clickhouse針對每壹列都進行了分別存儲，並生成了.bin以及.mrk兩個文件。bin文件存儲了真正的列的值（內部又設計列的壓縮），mrk文件記錄了Mark numbers對應這個列的offset。以官網例子為例，Marks numbers為3對應了CounterID取值為[b,c,d,e]4個字符，查詢命中Marks numbers=3時，通過CounterID的mrk文件就可以知道這4個字符在CounterID的bin文件中存儲的offset，提高查詢性能。
（1）雖然是稀疏索引，但是如果索引中的列過多，則根據索引來劃分數據會更稀疏，建立的索引也需要更多，影響寫入性能，也會增加內存的使用
（2）相比普通的B樹索引，稀疏索引需要的內存更少，但是可能導致需要掃描的行數比實際的多（以官網demo為例，例如查詢(e,1)命中第3個索引，則需要掃描{index_granularity}行的數據，但是其實內部(e,1)的數據只占了少部分，帶來了無效掃描）
（3）官網推薦是不需要去改"8192"這個值。我個人認為是除非妳要做為索引的這個列的值分布非常非常集中，可能幾w行數據才可能變化壹個取值，否則無需去做調大去建立更稀疏的索引，不過如果這個列這個集中的分布，也不大適合作為索引；如果要調小這個值，是會帶來索引列增加，但是同樣也會帶來內存使用增加、寫入性能受影響。
（4）有2個列組合做組合索引，壹個值比較稀疏、壹個值比較集中，要選稀疏的值放在第壹位。只能選擇壹個列做單索引，如果有2個備選的值，要選比較稀疏的。
ClickHouse Primary Keys