分区和索引
分区粒度根据业务特点决定，不宜过粗或过细。一般选择按天分区，也可指定为
tuple()；以单表 1 亿数据为例，分区大小控制在 10-30 个为最佳。
必须指定索引列，clickhouse 中的索引列即排序列，通过 order by 指定，一般
在查询条件中经常被用来充当筛选条件的属性被纳入进来；可以是单一维度，也
可以是组合维度的索引；通常需要满足高级列在前、查询频率大的在前原则；还
有基数特别大的不适合做索引列，如用户表的 userid 字段；通常筛选后的数据
满足在百万以内为最佳。
数据采样策略
通过采用运算可极大提升数据分析的性能。
数据量太大时应避免使用 select * 操作，查询的性能会与查询的字段大小和数
量成线性变换；字段越少，消耗的 IO 资源就越少，性能就会越高。
千万以上数据集用 order by 查询时需要搭配 where 条件和 limit 语句一起使用。
如非必须不要在结果集上构建虚拟列，虚拟列非常消耗资源浪费性能，可以考虑
在前端进行处理，或者在表中构造实际字段进行额外存储。
不建议在高基列上执行 distinct 去重查询，改为近似去重 uniqCombined。
多表 Join 时要满足小表在右的原则，右表关联时被加载到内存中与左表进行比
较。
存储
ClickHouse不支持设置多数据目录，为了提升数据io性能，可以挂载虚拟券组，
一个券组绑定多块物理磁盘提升读写性能；多数查询场景 SSD 盘会比普通机械
硬盘快 2-3 倍。