今天有同事问我，列存大宽表场景下，如果在多个列上有等值过滤条件，OceanBase 的性能是不是无法满足要求？
Hi 晓楚，帮评估个OTS替换场景 大概1亿大宽表，查询姿势就是任意字段的组合，进行等值查询+group by/sum这些聚合操作，业务模型大概是这样1亿表，过滤性最强的字段会扫50万左右数据，单SQL OTS现在不超过300毫秒，这个场景能搞定不？主要也要求OB几百毫秒，我还有个疑问，这种场景是不是没有索引合并的能力耗时很难满足业务要求呢？
.
典型 SQL 如下：
200+字段的大宽表，sql大概就是 select sum(xx),count(*) from tb where a = ? and b = ? and c = ? group by d / order by d limit 20 类似这种
答案是：OceanBase 可以轻松搞定这种场景！
OceanBase 列存表是如何处理 a = ? and b = ? and c = ? 这种多个等值条件的扫描呢？
按照一般的思路，我们会将这三个表达式下压到存储层。存储层需要先按照 a = ? 扫描出所有结果行，得到第一组rowid，然后按照 b = ? 扫描出所有结果行，得到第二组rowid，最后按照 c = ? 扫描出所有结果行，得到第三组rowid，然后把这三组 rowid 求交集，得到最终结果。
这个思路并没有什么问题，在最坏的情况下我们就是这么做的。因为只需要扫描三列，一般是可以做得非常快的。1亿行，百毫秒级绰绰有余。
但实际上，OceanBase 存储层做了更多优化。比如，首先做 a = ? 扫描的时候，就可以快速知道哪些微块上根本没有满足条件的数据，那么在处理 b = ? 和 c = ? 时就可以快速跳过这样的微块。
再比如，在先计算哪个条件的选择上，可以选择过滤性最好的条件先做，这样就可以跳过更多的微块。
还比如，过滤性不确定的情况下，还可以动态地选择三个表达式中的一个来做，做一段时间发现过滤性不好，就换另一个表达式。这样动态切换，可以让计算过程具备更好的自适应能力。
对于 OceanBase 来说， a = ? and b = ? and c = ? 是最好处理的场景了，实际场景可以比这个复杂得多，比如还有 or 条件的时候应该怎么处理？这些 OceanBase 都有相应的优化策略。
基于存储层的这些优化，我们在 5000万行的数据集下做了一些简单测试，结果如下：
可以看到，在两个过滤条件的场景下，5000万行的表，只需要 50 毫秒即可过滤出结果。由此推算，1亿行的场景，也一定可以满足客户对延迟的需求。
