之前的跳表索引专利写的不够详细,第二版把细节给整完备

第二版修改点:

一. 相关概念介绍不完整, 补充相关名词解释, 以及说明业务场景

名词解释:

• 知识网格与元数据
• 列式存储
• 向量化读取(pack)

业务场景:

• 具体说明在分析股票的时间范围内的数据指标时的场景

二.对现有的innodb的B+索引方案的不足做突出强调,针对性说明如何解决

innodb的B+树索引问题:

1. innodb的B+树索引维护负担大，无法应用于全部的列
2. innodb的B+树索引高度与数据量相关, 随着数据量增加引发范围查询的性能问题

针对性说明如何解决:

1. 为何新的索引结构的维护负担小
2. 为何不会随着数据量增加导致性能下降

三. 自适应跳表索引的完整的生命周期, 需补充完整

生命周期划分:

1. 索引的生成时机, 第一次构建出该索引, 需要考虑生成的耗时
2. 索引的销毁时机,与mysqld服务生命周期相同的话,需要考虑对内存的占用, 以及为了其他模块内存使用而销毁索引的问题
3. 索引的更新时机

四. 在SQL语法支持上，添加用户可以自定义对特定列添加跳表索引

说明用户可以自定义后

1. 对用户的便利性的影响
2. 对索引生成时机的影响

五. 需要说明索引结构为什么可以不用支持事务隔离

说明点:

1. 从使用场景入手,说明范围查询分析可以容忍一定时间内的过期数据
2. 从跳表的数据结构与更新时机入手, 说明索引最终指向的是物理列的地址索引, 即使索引过期, 当真实的物理列地址变化时,可以使用变化的版本，用以控制是否数据已变化, 如果变化则数据已经过期, 超过一定数量则更新索引，可容忍则返回结果

六. 索引支持的数据类型

• 为了性能当前只支持整型和单精度浮点型
• 以clickhouse的算法优化为例说明不同的数据类型有其最适用的算法和数据结构