在 ClickHouse 進程中，CPU 的主頻越高越好，通常建議使用 32 以上的機型，內存越大越好，一般每個線程分配 2GB 內存差不多就夠了，當然越大的內存加速就會越明顯。
磁盤通常普通的 HDD 磁盤都可以，RAID 方面 RAID-5、RAID-10 或者 RAID-50 都可以。如果查詢數據量大、延遲要求比較低的話，使用 SSD/NVME 這些高速設備是最好的。
因為 ZK 節點不能混布，如果混布會出現很多的問題，比如相互影響導致集群無法工作，如果數據量在 TB 級別的時候，會選擇一個 SSD 盤之類的高速設備。
我們整理了一些基礎的參數：
lmax_threads: 查詢使用的線程數量，默認為核數一半；
lmax_memory_usage: 單次查詢允許使用的內存量；
lmax_memory_usage_for_all_users：ClickHouse 進程允許使用的內存量, 通常需要考慮為 OS 預留內存；
lmax_bytes_before_external_group_by: GROUP BY 操作使用內存超過該閾值后， 數據會寫入磁盤，建議設置為 max_memory_usage/2；
lmax_concurrent_queries: 最大並發數限制；
lmax_bytes_before_external_sort: order by 排序溢寫磁盤閾值；
lbackground_pool_size: 后台線程組 。
在使用層面也有一些建議：
避免全表掃描
-查詢是需要指定分區
-避免使用 SELECT *
-GROUP BY 需要指定 LIMIT 子句
常用請求使用物化視圖預計算， 例如監控⻚面，報表大盤等
關聯查詢時慎用 JOIN，可以考慮優先使用 IN 解決
JOIN 查詢有損性能
-小表在右
-減少參與 JOIN 運算的數據量 (無謂詞下推)
數據寫入
-避免小批次寫入
-批量寫入數據中不宜包含過多分區
-適當調大后台 merge 線程數 background_pool_size
分布式表提供查詢，代理 + 本地表提供數據寫入
合理規划ZK集群配置以及參數調整建議
-數據規模在 TB 級別，建議使用 SSD 磁盤
-開啟自動清理數據功能
為用戶設置配額
下面我們講一下查詢方面的優化。最簡單的來說，對於一條 SQL 語句，我們要看它的延遲，如果延遲的結果不一樣，我們就會通過日志和其他的方式來看，哪些數據被掃描了、掃描了多少數據、用到內存多少、有沒有寫出到磁盤、使用了哪些條件，甚至可以查看執行計划，這些就是查詢優化常規的步驟。
最新版本的 ClickHouse，已經提供了 explain 命令，可以看整個查詢的執行計划，這樣查詢語句合理不合理都可以再次調整，比以前方便很多，以前通過日志后台看，這對很多的其他開發者是不太友好的。