Hypertable查询语句的scan_and_filter_rows选项解析

    在where子句后有大数量的row="" 的条件时，使用该选项可以提高查询性能。因为默认情况下，每个row条件会起一个异步的查询，每个查询都需要进行一次网络的往返。而该选项会将所有的row条件先进行排序，然后以最小的row作为条件启动一个异步查询，即获取最小的row所在的range。如果该range中没有包含所有的 row，则下一个异步查询将从最新的row开始。

    上面的说法可能有些抽象了，还是用例子说明问题吧。例如：where (row="1" or row="2" or row="3") ，假设row为"1"和"2"都落在同一个range(A)中。默认情况下，将会启动三个异步查询，第一个查询row="1",依次类推，此时，A将被访问两次。使用scan_and_filter_rows时,以row="1"为条件启动一个异步查询，当然此查询将针对A。在A中将获取到row="1"和row="2"，但是没有row="3"。为了获取到后者，必须以row="3"为条件启动第二次异步查询。此时，A只被访问一次。

    可见，scan_and_filter_rows选项减少了异步查询的数量，并将并发的多个异步查询变成了少量串行的异步请求，所以说它减少了网络往返的损耗。社区介绍说：在where子句后有非常多的独立条件时，可通过该选项来提高查询性能。但是我在测试时，where子句后的条件数目达到5000+时，使用该选项的耗时仍然比不使用的耗时大的多。

    另外请注意，针对类如where ("1"<=row<="2" or row="3")这样的查询，请不要使用scan_and_filter_rows选项。因为它将只处理"1"<=row<="2"条件的下限，即row="1"，即返回的结果只有row="1"和row="3"，这显然不是我们所希望的。或许社区以后会改善这个问题，但是起码截止hypertable0.9.7.7版本，本问题仍然没有改善。