ClickHouse基础知识及与MySQL性能对比( 四 ) _索引

alter操作
// ALTER只支持MergeTree系列，Merge和Distributed引擎的表，基本语法：ALTER TABLE [db].name [ON CLUSTER cluster] ADD|DROP|MODIFY COLUMN ...// 参数解析：ADD COLUMN – 向表中添加新列DROP COLUMN – 在表中删除列MODIFY COLUMN – 更改列的类型// 案例演示：新增字段：alter table tableNameadd columnnewcolnameString after col1修改字段类型：alter table tableNamemodify columnnewcolnameString；删除字段：alter table tableNamedrop columnnewcolname;
table
// 查看表结构hadoop102 :) desc dis_table;DESCRIBE TABLE dis_table┌─name─┬─type───┬─default_type─┬─default_expression─┬─comment─┬─codec_expression─┬─ttl_expression─┐│ id│ UInt16 │││││││ name │ String ││││││└──────┴────────┴──────────────┴────────────────────┴─────────┴──────────────────┴────────────────┘2 rows in set. Elapsed: 0.001 sec.
数据压缩通用编码特殊编码
特殊编码与通用的压缩算法相比，区别在于，通用的LZ4和ZSTD压缩算法是普适行的，不关心数据的分布特点，而特殊编码类型对于特定场景下的数据会有更好的压缩效果。
使用
压缩算法和特殊编码两者可以结合起来一起使用
CREATE TABLE k19_ods.test8 (`found _time` Uint32,`recv_timet` UInt32 CODEC ( NONE ),`recv_time2` UInt32,`recv_time3` Ulnt32 CODEC ( LZ4 ),`recv_time4` UInt32 CODEC (LZ4HC ( 9 )),`recv_time5` UInt32 CODEC (ZSTD ( 9 ),`recv_time6` Ulnt32 CODEC ( T640 ),`name0` String CODEC (Delta (, LZ4 ),`name1` String CODEC ( DoubleDelta0 )),`name2` String CODEC ( Gorilla ( 0 ), `name4` String cODEC ( Gorilla ), Lz4 ) ) ENGINE = MergeTree () PARTITION BYtoYYYYMMDD ( toDateTime(found_time )) ORDER BYfound_time
压缩效果对比
对于LZ4HC和ZSTD选择的压缩level越高，压缩效果越好，但是CPU的使用率也会相应的越高。如果插入的数据量很大,会明显看到较高的CPU使用率。
索引
的索引由于其存储引擎的设计，可以做的非常简单。主要有一级索引和标记组成。一级索引实现数据到block的映射，标记实现block到文件偏移量的实现。另外，由于一级索引非常小，1亿条数据只需要1万多行的索引，因此一级索引可以常驻内存，加速查找。
同时，还提供了二级索引，不过二级索引比较简单，且不是必须的，对整体性能影响也不大。
稀疏索引
首先，的一级索引使用了一种叫做稀疏索引的技术，那么何为稀疏索引呢？既然有稀疏索引，是不是相对的也有稠密索引呢？没错，确实有。二者的区别如下：
稠密索引：每行数据记录都会对应一行索引标记。
稀疏索引：每隔若干行记录对应一条索引标记。
既然概念清楚了，那么使用稀疏索引带来的好处也是显而易见的，那就是可以大幅减少索引占用的空间。以默认的索引力度8192为例，1亿行数据只需要存储12208行索引。因为占用空间小，中一级索引的数据是常驻内存的，所以取用速度极快。
那么稠密索引也有其好处，因为每条记录都有索引，所以查询的时候可以一步到位，当然缺点就是会占用较多的空间，像mysql的主键索引即是使用的稠密索引。
索引粒度
索引粒度对应的是这个参数，前一节我们已经说了使用的是稀疏索引的方式，那么这个参数就是决定每隔多上行数据生成一条索引记录了，默认是8192，新版本的已经提供了自适应粒度大小的特性。