1，查詢強烈要求帶上分區鍵過濾和主鍵過濾，如 where day = today() and itime = now()。
2，建表的時候，選擇合適的分區鍵和排序鍵是優化的關鍵。
3，如果不允許重復主鍵(且不要求去重時效性)，建議使用表類型：ReplicatedReplacingMergeTree 建表語句可參考 /blog/2019/3/27/low-cardinality 。
7，為了使復雜查詢盡量本地完成，提前減小數據量和網絡傳輸，加快查詢速度，創建分布式表時，盡量按照主鍵hash分shard。例如欲加快select count(distinct uid) from table_all group by country, os的查詢速度. 創建分布式表table_all時，shard key為cityHash64(country, os)，hash函數參考 https://clickhouse.tech/docs/en/sql-reference/functions/hash-functions/ 。
8，計算不同維度組合的指標值時，用with rollup或with cube替代union all子句。
9，建表時，請遵守命名規範：分布式表名 = 本地表名 + 後綴"_all"。 select請直接操作分布式表。
10，官方已經指出Nullable類型幾乎總是會拖累性能，因為存儲Nullable列時需要創建壹個額外的文件來存儲NULL的標記，並且Nullable列無法被索引。因此除非極特殊情況，應直接使用字段默認值表示空，或者自行指定壹個在業務中無意義的值（例如用-1表示沒有商品ID）
11，稀疏索引不同於mysql的B+樹，不存在最左的原則，所以在ck查詢的時候，where條件中，基數較大的列（即區分度較高的列）在前，基數較小的列（區分度較低的列）在後。
12，多表Join時要滿足小表在右的原則，右表關聯時被加載到內存中與左表進行比較
13，多維分析, 查詢列不宜過多, 過濾條件帶上分區篩選 (select dim1, dim2, agg1(xxx), agg2(xxx) from table where xxxx group by dim1, dim2 )
14，禁止SELECT *, 不能拉取原始數據!!!! (clickhouse不是數據倉庫, 純粹是拉原始表數據的查詢應該禁止,如 select a, b, c, f, e, country from xxx )
分區鍵和排序鍵理論上不能修改，在建表建庫的時候盡量考慮清楚 。
0，事實表必須分區，分區粒度根據業務特點決定，不宜過粗或過細。我們當前都是按天分區，按小時、周、月分區也比較常見（系統表中的query_log、trace_log表默認就是按月分區的）。
1，分區鍵能過濾大量數據，分區鍵建議使用toYYYYMMDD()按天分區，如果數據量很少，100w左右，建議使用toYYYYMM()按月分區，過多的分區會占用大量的資源，會對集群的穩定性造成很大的影響。
2，分區鍵必須使用date和datetime字段，避免string類型的分區鍵
3，每個sql必須要用分區鍵，否則會導致大量的數據被讀取，到了集群的內存限制直接拒絕
4，排序鍵也是壹個非常重要的過濾條件，考慮到ck是OLAP 庫，排序鍵默認也是ck的主鍵，loap庫建議分區鍵要使用基數比較少的字段，比如country就比timestramp要好。
5，不要使用過長的分區鍵，主鍵 。
6，CK的索引非MySQL的B樹索引，而是類似Kafka log風格的稀疏索引，故不用考慮最左原則，但是建議基數較大的列（即區分度較高的列）在前，基數較小的列（區分度較低的列）在後。另外，基數特別大的列（如訂單ID等）不建議直接用作索引。
分區數過多會導致壹些致命的集群問題。 不建議分區數粒度過細，不建議分區數過多 ，經驗來看，10億數據建議1-10個分區差不多了，當然需要參考妳的硬件資源如何。
1，select 查詢性能降低，分區數過多會導致打開大量文件句柄，影響集群。
2，分區數過多會導致集群重啟變慢，zk壓力變大，insert變慢等問題。
https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/custom-partitioning-key/