一、優點：
1.為了高效的使用CPU，數據不僅僅按列存儲，同時還按向量進行處理；
2.數據壓縮空間大，減少IO；處理單查詢高吞吐量每台服務器每秒最多數十億行；
3.索引非B樹結構，不需要滿足最左原則；只要過濾條件在索引列中包含即可；即使在使用的數據不在索引中，由於各種並行處理機制ClickHouse全表掃描的速度也很快；
4.寫入速度非常快，50-200M/s，對於大量的數據更新非常適用。
二、缺點：
1.不支持事務，不支持真正的刪除/更新；
2.不支持高並發，官方建議qps為100，可以通過修改配置文件增加連接數，但是在服務器足夠好的情況下；
3.SQL滿足日常使用80%以上的語法，join寫法比較特殊；最新版已支持類似SQL的join，但性能不好；
4.盡量做1000條以上批量的寫入，避免逐行insert或小批量的insert，update，delete操作，因為ClickHouse底層會不斷的做異步的數據合並，會影響查詢性能，這個在做實時數據寫入的時候要盡量避開；
5.Clickhouse快是因為采用了並行處理機制，即使一個查詢，也會用服務器一半的CPU去執行，所以ClickHouse不能支持高並發的使用場景，默認單查詢使用CPU核數為服務器核數的一半，安裝時會自動識別服務器核數，可以通過配置文件修改該參數。
全量數據導入：數據導入臨時表 -> 導入完成后，將原表改名為tmp1 -> 將臨時表改名為正式表 -> 刪除原表
增量數據導入： 增量數據導入臨時表 -> 將原數據除增量外的也導入臨時表 -> 導入完成后，將原表改名為tmp1-> 將臨時表改成正式表-> 刪除原數據表
三、優化：
1.關閉虛擬內存，物理內存和虛擬內存的數據交換，會導致查詢變慢。
2.為每一個賬戶添加join_use_nulls配置，左表中的一條記錄在右表中不存在，右表的相應字段會返回該字段相應數據類型的默認值，而不是標准SQL中的Null值。
3.JOIN操作時一定要把數據量小的表放在右邊，ClickHouse中無論是Left Join 、Right Join還是Inner Join永遠都是拿着右表中的每一條記錄到左表中查找該記錄是否存在，所以右表必須是小表。
4.批量寫入數據時，必須控制每個批次的數據中涉及到的分區的數量，在寫入之前最好對需要導入的數據進行排序。無序的數據或者涉及的分區太多，會導致ClickHouse無法及時對新導入的數據進行合並，從而影響查詢性能。
5.盡量減少JOIN時的左右表的數據量，必要時可以提前對某張表進行聚合操作，減少數據條數。有些時候，先GROUP BY再JOIN比先JOIN再GROUP BY查詢時間更短。
6.ClickHouse的分布式表性能性價比不如物理表高，建表分區字段值不宜過多，防止數據導入過程磁盤可能會被打滿。
7.CPU一般在50%左右會出現查詢波動，達到70%會出現大范圍的查詢超時，CPU是最關鍵的指標，要非常關注。
四、性能情況：
1.單個查詢吞吐量：如果數據被放置在page cache中，則一個不太復雜的查詢在單個服務器上大約能夠以2-10GB／s（未壓縮）的速度進行處理（對於簡單的查詢，速度可以達到30GB／s）。如果數據沒有在page cache中的話，那么速度將取決於你的磁盤系統和數據的壓縮率。例如，如果一個磁盤允許以400MB／s的速度讀取數據，並且數據壓縮率是3，則數據的處理速度為1.2GB/s。這意味着，如果你是在提取一個10字節的列，那么它的處理速度大約是1-2億行每秒。對於分布式處理，處理速度幾乎是線性擴展的，但這受限於聚合或排序的結果不是那么大的情況下。
2.處理短查詢的延時時間：數據被page cache緩存的情況下，它的延遲應該小於50毫秒(最佳情況下應該小於10毫秒)。 否則，延遲取決於數據的查找次數。延遲可以通過以下公式計算得知： 查找時間（10 ms） * 查詢的列的數量 * 查詢的數據塊的數量。
3.處理大量短查詢：ClickHouse可以在單個服務器上每秒處理數百個查詢（在最佳的情況下最多可以處理數千個）。但是由於這不適用於分析型場景。建議每秒最多查詢100次。
4.數據寫入性能：建議每次寫入不少於1000行的批量寫入，或每秒不超過一個寫入請求。當使用tab-separated格式將一份數據寫入到MergeTree表中時，寫入速度大約為50到200MB/s。如果您寫入的數據每行為1Kb，那么寫入的速度為50，000到200，000行每秒。如果您的行更小，那么寫入速度將更高。為了提高寫入性能，您可以使用多個INSERT進行並行寫入，這將帶來線性的性能提升。
count: 千萬級別，500毫秒，1億 800毫秒 2億 900毫秒 3億 1.1秒
group: 百萬級別 200毫米，千萬 1秒，1億 10秒，2億 20秒，3億 30秒
join：千萬-10萬 600 毫秒， 千萬 -百萬：10秒，千萬-千萬 150秒
ClickHouse並非無所不能，查詢語句需要不斷的調優，可能與查詢條件有關，不同的查詢條件表是左join還是右join也是很有講究的。
五、其他：
1.MySQL單條SQL是單線程的，只能跑滿一個core，ClickHouse相反，有多少CPU，吃多少資源，所以飛快；
2.ClickHouse不支持事務，不存在隔離級別。ClickHouse的定位是分析性數據庫，而不是嚴格的關系型數據庫。
3.IO方面，MySQL是行存儲，ClickHouse是列存儲，后者在count()這類操作天然有優勢，同時，在IO方面，MySQL需要大量隨機IO，ClickHouse基本是順序IO。
有人可能覺得上面的數據導入的時候，數據肯定緩存在內存里了，這個的確，但是ClickHouse基本上是順序IO。對IO基本沒有太高要求，當然，磁盤越快，上層處理越快，但是99%的情況是，CPU先跑滿了（數據庫里太少見了，大多數都是IO不夠用）。