...

1. 在cache不满时，如果进行预读操作，对于一个sensor来讲，因为会预读出另外的999个sensor的TimeSeriesMetadata，并且当遍历到下一个sensor时，之前预读的TimeSeriesMetadata早已被踢出去了，所以cache的命中率一直是0%，所以每个文件的每个sesnor会进行1000次map的put操作，所以总计进行了100,000,000次put操作(这put操作耗时也包含了，某次put操作后，cache满了，踢出部分缓存的耗时)，以及100,000次反序列化TimeSeriesMetadata操作。
2. 如果我们不进行预读操作，每次读取只将对应的sensor的TimeSeriesMetadata放进cache中，那每个文件的每个sesnor会进行1次map的put操作，所以总计只进行了100,000次put操作，是上面的1/1000，以及100,000次反序列化TimeSeriesMetadata操作。
3. 而当我们关闭cache后，这100,000,000次的put操作耗时就都省去了，但是依然有100,000次反序列化TimeSeriesMetadata操作。
4. 若cache大于36MB，即能容纳该device下所有文件的所有sensor的timeseriesMetadata，遍历第一个sensor时，会进行100,000次put操作，将之后的999个sensor的timeseriesMetadata都缓存起来，遍历之后的sensor时，cache命中，所以不需要反序列化操作，即只进行了100次反序列化TimeSeriesMetadata操作。

实验场景一

开cache，分配给IoTDB总的内存100MB，读内存占3/10，即30MB，timeseriesMetadata占读内存的1/15，即2MB，也就是足够容纳5个文件的一个device的所有TimeSeriesMetadata。
耗时：36046ms

实验场景二

不进行预读操作，其余配置同实验一

耗时：21,619ms

...

关cache，其余配置同实验一
耗时：20,220ms

实验场景四

开cache，分配给IoTDB总的内存1000MB，读内存占3/10，即300MB，timeseriesMetadata占读内存的2/15，即40MB，也就是足够容纳100个文件的一个device的所有TimeSeriesMetadata。
耗时：6,177ms

实验验证

上面的四个场景，对应实验分析中的四个点，并且实验结果均符合实验分析，为了进一步验证这个结论，我们使用JProfiler对实际耗时进行统计，方便起见，我们选取场景一与场景二进行抽样

                               场景一                                                                                                                                                                                             场景二

可以看到，场景一的耗时比场景二就是多在forEach那边，也就是多出来的99,900,000次put操作

验证GroupBy的执行流程

对于GroupBy查询，我们并不是迭代完一个sensor的所有区间，再去迭代下一个sensor，我们是对于一个groupby的时间窗口，迭代所有的sensor，所以如果是对于groupby查询而言，只要cache能够容纳一个时间窗口的所有sensor的TimeSeriesMetadata，就能保证cache命中率，不会出现上面的cache抖动现象。

...

一个时间窗口包含了10个文件，每个文件1000个sensor，因为还需要再读一个文件，才能判断时间窗口的结束，所以按照分析，只要cache能够容纳11,000个TimeSeriesMetadata即可，即需要cache > 4.04MB，我们设置cache为4.1MB，执行上面这条查询只需要31MB，执行上面这条查询只需要3,553ms，cache命中率99266ms，cache命中率99.9%.

验证了我们对于GroupBy查询流程的分析。

验证cache满后对后续查询的影响

当前一个查询将cache占满后，cache本身的最大size能满足下一个查询的需求，此时不应该对下一个查询产生影响。

设定cache为4.1MB

先执行select last_value(*) from root.sg1.d0 groupby([0,100),10ms)

耗时为2,293ms

此时cache已经占满，再执行select last_value(*) from root.sg1.d1 groupby([0,100),10ms)，查询另一个device的

耗时为2,313ms

可以看到，确实没有影响。