UInt8,UInt16,UInt32,UInt64,Int8,Int16,Int32,Int64:
固定長度的整型，包括有符號整型或無符號整型
整型范圍
* Int8-[-128:127]
* Int16-[-32768:32767]
* Int32-[-2147483648:2147483647]
* Int64-[-9223372036854775808:9223372036854775807]
無符號整型范圍
* UInt8-[0:255]
* UInt16-[0:65535]
* UInt32-[0:4294967295]
* UInt64-[0:18446744073709551615]
Float32,Float64
浮點數
Float32 - float
Float64 - double
對浮點數進行計算可能引起四舍五入的誤差
Decimal(P,S),Decimal32(S),Decimal64(S),Decimal128(S)：
有符號的定點數，可在加、減和乘法運算過程中保持精度。對於除法，最低有效數字會被丟棄（不舍入）
P - 精度。有效范圍：[1:38]，決定可以有多少個十進制數字（包括分數）。
S - 規模。有效范圍：[0：P]，決定數字的小數部分中包含的小數位數。
對於不同的 P 參數值 Decimal 表示，以下例子都是同義的：
-P從[1:9]-對於Decimal32(S)
-P從[10:18]-對於Decimal64(小號)
-P從[19:38]-對於Decimal128（S)
十進制值范圍
* Decimal32(S) - ( -1 * 10^(9 - S),1*10^(9-S) )
* Decimal64(S) - ( -1 * 10^(18 - S),1*10^(18-S) )
* Decimal128(S) - ( -1 * 10^(38 - S),1*10^(38-S) )
內部表示方式
數據采用與自身位寬相同的有符號整數存儲。這個數在內存中實際范圍會高於上述范圍，從 String 轉換到十進制數的時候會做對應的檢查。
由於現代CPU不支持128位數字，因此 Decimal128 上的操作由軟件模擬。所以 Decimal128 的運算速度明顯慢於 Decimal32/Decimal64。
運算和結果類型
對Decimal的二進制運算導致更寬的結果類型（無論參數的順序如何）。
* Decimal64(S1) <op> Decimal32(S2) -> Decimal64(S)
* Decimal128(S1) <op> Decimal32(S2) -> Decimal128(S)
* Decimal128(S1) <op> Decimal64(S2) -> Decimal128(S)
精度變化的規則：
* 加法，減法：S = max(S1, S2)。
* 乘法：S = S1 + S2。
* 除法：S = S1。
對於 Decimal 和整數之間的類似操作，結果是與參數大小相同的十進制。
未定義Decimal和Float32/Float64之間的函數。要執行此類操作，您可以使用：toDecimal32、toDecimal64、toDecimal128 或 toFloat32，toFloat64，需要顯式地轉換其中一個參數。注意，結果將失去精度，類型轉換是昂貴的操作。
Decimal上的一些函數返回結果為Float64（例如，var或stddev）。對於其中一些，中間計算發生在Decimal中。對於此類函數，盡管結果類型相同，但Float64和Decimal中相同數據的結果可能不同。
Boolean:
沒有單獨的類型來存儲布爾值。可以使用 UInt8 類型，取值限制為 0 或 1
String:
字符串可以任意長度的。它可以包含任意的字節集，包含空字節。因此，字符串類型可以代替其他 DBMSs 中的 VARCHAR、BLOB、CLOB 等類型
ClickHouse 沒有編碼的概念。字符串可以是任意的字節集，按它們原本的方式進行存儲和輸出。
若需存儲文本，建議使用 UTF-8 編碼。至少，如果終端使用UTF-8（推薦），這樣讀寫就不需要進行任何的轉換了
Fixedstring:
固定長度 N 的字符串（N 必須是嚴格的正自然數）<column_name> FixedString(N)
當數據的長度恰好為N個字節時，FixedString類型是高效的。 在其他情況下，這可能會降低效率
UUID:
通用唯一標識符(UUID)是用於標識記錄的16字節數
如果在插入新記錄時未指定UUID列值，則UUID值將用零填充00000000-0000-0000-0000-000000000000
用法示例
限制
UUID數據類型僅支持以下功能 字符串 數據類型也支持（例如, min, max，和 計數).
算術運算不支持UUID數據類型（例如, abs）或聚合函數，例如 sum 和 avg
Date:
日期類型，用兩個字節存儲，表示從 1970-01-01 (無符號) 到當前的日期值。允許存儲從 Unix 紀元開始到編譯階段定義的上限閾值常量（目前上限是2106年，但最終完全支持的年份為2105）。最小值輸出為1970-01-01
Datetime64:
允許存儲時間instant間，可以表示為日歷日期和一天中的時間，具有定義的亞秒精度。刻度尺寸（精度）：10-精度 秒
語法：DateTime64(precision, [timezone])
在內部，存儲數據作為一些 ‘ticks’ 自紀元開始(1970-01-01 00:00:00UTC)作為Int64. 刻度分辨率由precision參數確定。 此外，該 DateTime64 類型可以存儲時區是相同的整個列，影響如何的值 DateTime64 類型值以文本格式顯示，以及如何解析指定為字符串的值 (‘2020-01-01 05:00:01.000’). 時區不存儲在表的行中（或resultset中），而是存儲在列元數據中
用法示例:
Enum8,Enum16:
Enum 保存 'string'= integer 的對應關系。在 ClickHouse 中，盡管用戶使用的是字符串常量，但所有含有 Enum 數據類型的操作都是按照包含整數的值來執行。這在性能方面比使用 String 數據類型更有效。
Enum8 用 'String'= Int8 對描述。
Enum16 用 'String'= Int16 對描述。
用法示例
LowCardinality Data Type:
把其它數據類型轉變為字典編碼類型 LowCardinality(data_type)
參數：data_type — String, FixedString, Date, DateTime，包括數字類型，但是Decimal除外。對一些數據類型來說，LowCardinality 並不高效，詳查allow_suspicious_low_cardinality_types設置描述
LowCardinality 是一種改變數據存儲和數據處理方法的概念。 ClickHouse會把 LowCardinality 所在的列進行dictionary coding。對很多應用來說，處理字典編碼的數據可以顯著的增加SELECT查詢速度。
使用 LowCarditality 數據類型的效率依賴於數據的多樣性。如果一個字典包含少於10000個不同的值，那么ClickHouse可以進行更高效的數據存儲和處理。反之如果字典多於10000，效率會表現的更差。
當使用字符類型的時候，可以考慮使用 LowCardinality 代替Enum。 LowCardinality 通常更加靈活和高效
用法示例:
