关于OceanBase 的int类型问题

OceanBase 到目前为止，最新版本为0.4，其int类型实现，底层均采用int64来存储，二进制的结构如下：

[len][数值]

如：128 的实际存储为：16进制显示：01 80 

其中01为长度，占用1字节，80即10进制的128

优点：

在schema中，只要是数值类型(非小数），全部定义成int类型.  管理较少的数据类型，DBA、开发都比较轻松。

缺点：

     1.在存储数值较小时，空间浪费严重.  如：flag字段，业务上常用值为：1-9之间，OceanBase中，每个值都要用2字节来存储。

      2.CPU浪费: 虽然每次读写，均基于block来操作，每次内存中，都需要对int类型做长度解析，无论在updateServer 、还是chunkServer ，都不划算.

      3.Schema的作用就是为数据更快查询，提供依据，如mysql类型划分为：tinyint、smallint、mediumint、int、bigint.  显然，在已知长度的情况下的block解析速度，要更加快速。

      有人拿Oracle说事，说Oracle只有一个number数据类型呀：

      你对Oracle Number数据类型结构，又知多少呢？

      Oracle数值类型二进制存储解析：

        Oracle number类型存储的本质，是有效数字存储，number的类型 是有效数字的个数，详细的block存储结构中的number存储，会贴到我的博客分类oracle中.

       Oracle number类型 按照科学计数法来存储，其长度也是固定的，比如number(6) ，仅仅占用的字节4个.

     4.当在二级索引中含有int类型字段时，这种定长的查询解析，为优化器提供了可以优化的方式：

     如：联合索引：

        [emp_no(medium int) ][name(varchar2(32))]

     当数据库中有这样一个联合索引，并且，你的查询条件是按照name来查询。 where name = xxxxx

     Oracle 是可以实现，跨越式扫描的。  这种扫描，说白了，利用到了字段的定长，跳过了emp_no的解析，直接解析name.  提供了更高的效率。(当然，这里他会权衡，全表扫描与索引扫描的优劣)

     这种功能，鲜有人提及，mysql中 没有实现的.

      总结：

             纵观OceanBase的发展历程，从BigTable的初步模仿和借鉴，到今天SQL版本的发布，其进步相当值得肯定。在底层存储的设计上，跟主流DB有小小的差异，是可以理解的。

           退一步说，即使按照len[val]来存储，也要能够通过schema定位出来，这个列占用的 真实长度。

            毕竟OceanBase 到目前还没有二级索引的功能，相信二级索引功能增加以后，优化器的选择必将推动底层优化。

           从DBA角度，把Schema的权限交给DBA去权衡，体现了DB的设计者，将空间与时间的换算交给DBA、交给业务去权衡; DB不是搜索引擎，透明、开放、易用 是它的典型特点.