clickhouse常规的优化方法

一、建表优化

1.1日期字段避免使用String存储

建表时能用数值型或日期时间型表示的字段就不要用字符串，全String 类型在以Hive
为中心的数仓建设中常见，但ClickHouse 环境不应受此影响。
虽然ClickHouse 底层将DateTime 存储为时间戳Long 类型，但不建议存储Long 类型，因为DateTime 不需要经过函数转换处理，执行效率高、可读性好。

1.2 空值存储类型

在ClickHouse表中数据存储时，对于一些列尽量不使用Nullable类型存储，因为此类型需要单独创建额外的文件来存储NULL的标记并且Nullable类型列无法被索引，会拖累性能，在数据存储时如果有空值时，我们可以选择在业务中没有意义的值来替代NULL值。
比如：用户ID或商品ID，用-1表示没有ID

1.3 分区和索引

ClickHouse中一般选择按天分区，可以指定tuple()指定多个列为组合分区。如果不按天分区，每个分区数据量控制在800~1000万为宜。
建表时通过order by 指定索引列，可以指定tuple(),指定多个列为索引列，指定索引列时最好满足高基列在前、查询频率大的列在前的原则。基数过大的列不适合作为索引列，因为如果某列基数特别大，这种情况有索引和没索引效果一样。如用户表的userid 字段；通常筛选后的数据满足在百万以内为最佳。

在这些分区索引的作用下，进行数据查询时能够快速跳过不必要的数据分区目录，从而减少最终需要扫描的数据范围。

比如官方案例的hits_v1 表：

PARTITION BY toYYYYMM(EventDate) 
ORDER BY (CounterID, EventDate, intHash32(UserID)) 

visits_v1 表：

PARTITION BY toYYYYMM(StartDate) 
ORDER BY (