RocksDB本身只是一个KV存储，用户通过put(key,value)来写入key，或者通过get(key)接口来获取value，所以单从RocksDB而言，每条记录都是一个key-value。那么当RocksDB作为一个存储引擎接入到MySQL时，key-value结构如何存储表中各个索引，以及如何记录中各个列的信息是本文要具体讨论的。
RocksDB引擎与InnoDB引擎类似，也是采用索引组织表，无论是表(主键索引)还是二级索引都是以LSM tree方式组织，RocksDB记录主要包括三部分，key，value和meta三部分内容，具体见下表，后面通过介绍一条具体记录在RocksDB引擎中的存储格式再做详细说明。
我们创建表，并写入数据，如下：
- create table row_format(
- id int not null,
- c1 int,
- c2 char(10) not null,
- c3 char(10),
- c4 varchar(10),
- c5 varchar(10) not null,
- c6 blob,
- c7 binary(10) not null,
- c8 varbinary(10))
- engine=rocksdb;
- insert into row_format(id,c2,c4,c5,c7) values(1,'abc','abc','efg','111')
Key部分
由于表没有主键，所以实质是rowid：
实际数据：
index_id:索引的编号，全局唯一。
rowid:由于表没有主键，系统会产生一个bigint类型的rowid作为主键，占用8个字节，而InnoDB引擎的rowid占6个字节，需要注意的是rowid存储采用的大端的存储(高位存储低字节)，这里主要是为了memcompare。
Value部分
说明：
- Value的最前面部分(0x1b)就是存放记录的null信息。根据记录中可以为null字段的个数，确认需要占用的字节数，如果小于8个，则只需要一个字节。例子中，c1,c3,c4,c6,c8均可以为null，因此需要5个bit，所以用1个byte表示Null-flag即可，由于插入记录中，c4不为null，则对应的bit为0，也就是0x00011011。
- 对于null，无论是定长还是非定长数据类型，都不占用真实的存储空间，只需要一个bit位来表示为null即可。
- 空串’’与null，上面提到了null需要占一个标记位，而对于’’，如果是变长字段仍然需要存储长度信息，对于定长字段，则会补全。
- 对于变长字段，比如varchar，0x03 0x61 0x62 0x63数据有len+data组成，如果数据长度小于256，len只需要占用一个byte；如果len大于255，且小于65536，则需要占用2个字节，对于longblob类型，则需要占4个字节。
- 对于定长字段，不需要存长度信息直接存储data，如果不足则补充。补充字符有点诧异，对于char类型，补充0x20，对于binary类型，补充0x00。
- 对于lob类型，比如tinyblob，blob，mediumblob，longblob，以及对应的text类型，处理策略与varchar类似，存储长度的字节数根据数据类型的范围确定，比如blob长度占用2个字节，而longblob的长度占4个字节。所以在rocksdb里面，没有innodb中所谓“溢出页”的概念。对于innodb引擎，如果blob字段内容超过768字节，多余的data存储在溢出页，页内通过20个字节指向溢出页，主要包括第一个blob页的space_id,page_no和起始偏移，如果存在多个blob页，则页与页之间通过类似的方式进行关联。具体可以参考btr0cur.h文件中关于BTR_EXTERN_xxx相关的宏定义，以及接口btr_copy_externally_stored_field_prefix_low。
- 有关value部分的存储实现可以参考rocksdb引擎接口 convert_record_to_storage_format，convert_record_from_storage_format和innodb引擎接口row_mysql_store_col_in_innobase_format，row_sel_field_store_in_mysql_format。
meta部分
meta部分主要是SequenceID，这个SequenceID在事务提交时产生，主要用于RocksDB实现MVCC，用于可见性判断，此外meta中还包含flag信息，由于标示记录类型，put，delete，singleDelete等，具体而言Sequence占7个字节，flag占1个字节。
RocksDB索引格式
RocksDB中，所有的数据都是通过索引来组织，与InnoDB类似，也是索引组织表，每个索引有一个全局唯一的index_id。索引主要包括两类：主键索引和二级索引，前面介绍的记录格式，也就是主键索引的格式，包括key，value和meta三部分。二级索引也包含key，value和meta三部分，但是value中不包含任何数据，只是包含checksum信息。
主键索引
二级索引
对比InnoDB引擎(innodb_file_format=Barracuda，row_format=compact)
InnoDB记录格式
我们仍然以上面的表结构来看看InnoDB的存储格式。
- create table row_format(
- id int not null,
- c1 int,
- c2 char(10) not null,
- c3 char(10),
- c4 varchar(10),
- c5 varchar(10) not null,
- c6 blob,
- c7 binary(10) not null,
- c8 varbinary(10)) engine=innodb;
- insert into row_format(id,c2,c4,c5,c7) values(1,'1234','ab','efg','111');
记录内容
说明
- 03 02 0a，这里存的是长度信息，所有非null的变长列信息都逆序存在一起，这里按先后顺序是c5,c4,c2,这里innodb将char(10)也当作变长字段处理了。
- 1b存储的是null信息，与rocksdb对null处理一致。00 00 18 ff b5存储的是record-header。
- 00 00 00 00 28 00 00 00 00 01 01 03 83 00 00 01 36 01 10， 这三部分别是rowid，trxid和roll_ptr,分别占6个字节，6个字节和7个字节。
- 最后一部分是数据，null不占任何存储空间，与rocksdb处理类似。
整体而言，InnoDB记录格式包含了record_header(记录头信息)，占5个字节，主要包括记录号(heap_no),列数目,下一条记录的位置以及是否删除等信息。RocksDB则相对简单，只有整体的value-size，以及通过Meta中flag标示记录的状态put 或者是delete。InnoDB将变长列长度信息集中存放在一起，使得查找任意列的代价都差不多，而RocksDB的变长列信息则是放在每列的前面，访问最后一列需要逐一计算前面的列，才能定位。此外，由于InnoDB引擎与RocksDB引擎由于实现MVCC的机制不同，导致InnoDB引擎和RocksDB引擎需要存储的额外信息也不同。InnoDB实现MVCC依赖于回滚段信息，记录需要额外存储trxid和roll_ptr两个字段，分别是6个字节和7个字节(type,rsegid,pageNO,offset),其中type占一个bit位，标示insert 或者是update类型，rsegid回滚段id占7bit位，pageNo占4个字节，页内偏移占2个字节。RocksDB实现MVCC则是依赖于SequenceID，通过SequenceID来判断记录的可见性，SequenceID占7个字节。
细节上来说，RocksDB引擎和InnoDB引擎在处理null，char和varchar的方式类似，但InnoDB对于char类型做了优化，统一作为varchar处理。另外RocksDB引擎没有对blob做特殊处理。你可能会有疑问，RocksDB不是也有block_size吗，如果设置为16k，blob数据超过16k怎么办？对于InnoDB而言，由于表实质是以一个个page通过B-tree组织起来的，每个page是固定大小，当记录非常大时，就需要借助溢出页，通过链接的方式关联起来。而RocksDB中block_size只是一个压缩单位，并没有严格约束，文件内容以block组织，由于文件中block可能是压缩过的，因此每个block的大小不固定，通过偏移来定位具体某个block的位置。如果遇到大的blob数据，则可能这个block比较大，记录所有数据存储在一起，不会跨block。
对于索引长度限制也有所不同，对于InnoDB引擎来说，索引中单列长度不能超过767个字节，而RocksDB引擎单列长度不超过2048个字节，具体可以参考max_supported_key_part_length各自的实现；整个索引的长度，RocksDB和InnoDB都限制在3072个字节，实际上是server层的限制，因为它们的各自限制的长度都比server层的大。
