MergeTree 系列的引擎被设计用于插入极大量的数据到一张表当中。数据可以以数据片段的形式一个接着一个的快速写入，数据片段在后台按照一定的规则进行合并。相比在插入时不断修改（重写）已存储的数据，这种策略会高效很多。
主要特点:
-
存储的数据按主键排序。
这使得你能够创建一个小型的稀疏索引来加快数据检索。
-
支持数据分区，如果指定了 分区键 的话。
在相同数据集和相同结果集的情况下 ClickHouse 中某些带分区的操作会比普通操作更快。查询中指定了分区键时 ClickHouse 会自动截取分区数据。这也有效增加了查询性能。
-
支持数据副本。
ReplicatedMergeTree 系列的表提供了数据副本功能。更多信息，请参阅 数据副本 一节。
-
支持数据采样。
需要的话，你可以给表设置一个采样方法。
-
ORDER BY — 排序键。
可以是一组列的元组或任意的表达式。 例如: ORDER BY (CounterID, EventDate) 。
如果没有使用 PRIMARY KEY 显式的指定主键，ClickHouse 会使用排序键作为主键。
如果不需要排序，可以使用 ORDER BY tuple().
-
PRIMARY KEY - 主键，如果要 选择与排序键不同的主键，可选。
默认情况下主键跟排序键（由 ORDER BY 子句指定）相同。 因此，大部分情况下不需要再专门指定一个 PRIMARY KEY 子句。
在类似ClickHouse这样纯列式的存储和计算引擎中，数据的压缩、计算、流转都是以列块为单位按列进行的。在ClickHouse中，只能对数据列以块为单位进行定位读取，虽然用户的查询是按照uid查询确定的某一条记录，但是从磁盘读取的数据量会被放大成块大小 * 列数
ClickHouse中的primary key索引有一个致命问题是，当前缀列的离散度(distinct value count)非常大时，在后续列上的过滤条件起到的"跳跃"加速作用就很微弱了。这个其实很好理解，当"跳跃数组"中相邻的两个元组是('a', 1)和('a', 10086)时，我们可以推断出第二列在对应的行号区间内值域是[1, 10086]；若相邻的元素是('a', 1)和('b', 10086)，则第二列的值域范围就变成(-inf, +inf)了，无法依据第二列的过滤条件进行跳过。
也就是，如果前缀是一样的话。可以跳过一定范围的索引块
测试后发现“基数大放前面”并没有很大帮助？反而导致mark更多了。所以应该按照如何有序，使得mark文件更小帮助更大？
--删除索引定义
Alter table index_test DROP INDEX tag_idx;
--增加索引定义
Alter table index_test ADD INDEX tag_idx tag TYPE range;
--清除数据分区下的索引文件
Alter table index_test CLEAR INDEX tag_idx tag in partition partition_expr;
--重新构建数据分区下的索引文件
Alter table index_test MATERIALIZE INDEX tag_idx tag in partition partition_expr;长主键将对插入性能和内存使用产生负面影响。
长主键不会对SELECT查询性能产生负面影响。
在插入过程中，所有列的缺失值将替换为默认值并写入表中。
测试发现TYPE set(100)不支持in查询？