背景
数据根据访问频率可以分为冷数据和热数据，并且冷数据的数据量会远大于热数据的数据量。为了节省成本，我们会倾向于将冷数据存放在便宜，存储空间大但性能并不是非常高的机械磁盘上，而将热数据存放在较贵，存储空间不是很大但性能较好的固态磁盘上。
由于用户很少访问几个月前的数据，蚂蚁的核心系统的数据有明显的冷热分布特点，因此，我们为核心系统建了历史库，历史库采用sata盘组成的raid作为底层存储，将时间较早的数据迁移到历史库上。做在线库数据删除时，迁移程序会先查询历史库保证数据在历史库存在再从在线库删除，发到历史库的sql是一个扫描几万的scan，由于历史库总数据量大并且查询的数据几乎是随机的，因为这些sql基本都要走io，最后出现少量的查询qps就将历史库磁盘io打满而cpu很空闲的情况，影响了历史库数据迁移速度。
现状
Oceanbase存储系统使用2M的宏块按range存储数据，为了避免读取几行数据也需要加载整个宏块到cache中，宏块内部又划分出很多个16K大小的微块（压缩前的大小），Oceanbase内部io的最小单位也是微块。
Oceanbase存储系统处理一个scan时，会先根据scan range找出需要访问的宏块，然后对要读取的前两个宏块的数据发起prefetch，对于在cache中命中的微块，工作线程会直接使用，对于宏块中cache miss的微块，工作线程会一次性发起多个异步io请求，每个io请求读取一个微块的数据，然后工作线程开始处理第一个宏块的数据，这中间如果之前预取发起的部分io未完成则需要等待。在第一个宏块的数据处理完后，工作线程会prefetch第三个宏块，然后开始处理第二个宏块的数据，如此循环，直至处理完所有宏块的数据。考虑到处理一个宏块数据的cpu耗时会小于一个宏块数据的io时间，后续可以考虑预取多个宏块的数据。
由于Oceanbase是以微块为单位发起异步io请求的，并且sata盘随机io性能比较差，在上述历史库迁移场景中，一条sql最终会转化成上百个微块粒度的小io，少量qps就会将sata盘的io打满。而ssd能提供较高的随机读iops，则没有这个问题。
优化方案
在预取一个宏块的数据时，我们不再以微块为粒度发起异步io，而是将相邻的在cache中miss的微块合并起来作为一个大io发起，这样做主要有以下两点好处：
- sata盘上只发一个io读一块数据会比发多个小io分别读数据的一部分执行要快，并且大的io size可以跑出更高的带宽；
- 异步io要求读取数据的offset和size都必须是4K对齐的，而16K的微块压缩完后基本不是4K对齐的，以微块为粒度做io每次io最坏情况下需要额外读8K的数据，会有比较严重的读取放大问题，而将多个微块的读取合并起来作为一个io能极大地缓解这个问题；
另外，为了应对scan的宏块中cache hit的微块和cache miss的微块大量交错的情况，如果cache hit的微块较少，则将cache hit的微块跟两边cache miss的微块一起放到一个io中，当然，已经在cache中命中的微块后续直接忽略不再解压进cache。
优化效果
测试方法
导入3T的tpch lineitem表数据，使用zstd压缩算法，开多个线程做scan，每个线程scan一个宏块的数据。开启io合并读时multiblock_read_size配为512KB。
测试环境
CPU ：64 core，Intel® Xeon® CPU E5-2682 v4 @ 2.50GHz
MEMORY : 500GB
DISK：12块TOSHIBA MG05ACA800E SATA盘组成的raid5
测试结果（时间为ms）
线程数 合并读 qps 95% rt avg rt max rt
10 关闭 59 249.79 166.45 419.79
10 开启 159 90.86 62.73 150.34
20 关闭 59 464.02 336.40 970.92
20 开启 196 148.89 101.76 236.83
30 关闭 59 668.26 501.78 996.27
30 开启 187 234.79 159.80 405.36
40 关闭 61 830.48 652.70 1047.55
40 开启 168 344.22 237.35 483.23
可以看出开启io合并读后qps是之前的两到三倍，有不错的效果。
