HBase过滤器深度解析：从核心机制到实战避坑指南-育师

1. 从一次线上查询事故说起：为什么需要HBase过滤器？

那天晚上，我正盯着监控大屏，突然收到告警：一个面向C端用户的查询接口响应时间从平时的几十毫秒飙升到了十几秒，并且还在持续恶化。快速定位后发现，问题出在一个基于HBase的用户行为流水查询上。业务逻辑很简单：根据用户ID和时间范围，从一张记录用户点击、浏览等事件的宽表中，取出特定类型的事件数据。当时的查询代码，是典型的“先全量Scan，再在客户端过滤”模式。随着数据量的增长和查询并发上升，这种模式瞬间成了性能瓶颈——网络I/O和客户端内存成了不可承受之重。

这次事故让我彻底明白了HBase过滤器（Filter）的核心价值：将过滤逻辑下推到服务端（RegionServer），在数据读取的最源头进行筛选，只返回真正需要的数据行（Row）或列（Column）。这不仅仅是减少网络传输的数据量，更重要的是，它极大地减轻了客户端的计算和内存压力，是构建高性能、可扩展的HBase应用不可或缺的基石。

很多人初学HBase API，会觉得过滤器只是查询条件的一种写法。但当你真正处理海量数据时，你会发现，是否使用过滤器、如何使用过滤器，直接决定了你的应用是“能用”还是“高效”。今天，我们就抛开那些简单的API罗列，深入HBase过滤器的内部机制、实战选型以及那些官方文档里不会写的“坑”，希望能帮你少走一些弯路。

2. 过滤器核心机制：服务端下推与执行流程拆解

要理解过滤器的威力，必须搞清楚它在HBase架构中的执行位置。一个没有过滤器的Scan操作，其数据流非常简单：客户端发起Scan请求，RegionServer定位到对应的Region，从HFile和MemStore中读取数据，然后将完整的KeyValue数据块通过网络发送回客户端。

而一旦你为Scan设置了过滤器，整个流程就发生了质的变化。这个过程可以拆解为以下几个核心阶段：

2.1 RegionServer端的过滤器初始化与执行

当你的Scan请求带着过滤器到达RegionServer时，过滤器对象会被序列化并传输过去。RegionServer在准备扫描一个Store（对应一个Column Family）的数据时，会实例化这个过滤器。关键点在于：过滤器的执行，是发生在RegionServer从底层存储（BlockCache, HFile, MemStore）读取每一个KeyValue数据单元的过程中，而不是在读取完所有数据之后。

想象一下RegionServer内部有一个数据流水线。扫描器（Scanner）从存储引擎拿到一个KeyValue（包含RowKey, Column Family, Column Qualifier, Timestamp, Value, Type等），在将其加入返回结果集之前，会先交给已设置的过滤器“过堂”。过滤器根据其内部逻辑，对这个KeyValue做出“判决”：

Include：这个KeyValue符合条件，允许加入结果集。
Skip：这个KeyValue不符合条件，跳过它，扫描器继续读取下一个。
Seek to next row/column：这是一个更高效的指令。例如，当某一行已被判定不需要时，过滤器可以命令扫描器直接跳到下一行（Seek to next row），跳过该行剩余的所有KeyValue，这避免了大量无用的磁盘I/O和比较操作。

2.2 过滤器的“必须”与“可能”语义

这是理解过滤器行为的一个高级概念，也是容易混淆的地方。在HBase中，过滤器可以返回一个Filter.ReturnCode，其中包含两个关键信息：include和skip。但更底层的，是过滤器的filterAllRemaining()和filterRow()方法。

filterRow(): 决定整行命运。在扫描完一行的所有相关列后，会调用此方法。如果返回true，则整行数据都会被过滤掉，不会发送给客户端。例如，SingleColumnValueFilter在找不到指定列，或列值不满足条件时，就可以通过配套的setFilterIfMissing(true)等方法，最终影响filterRow()的返回值，从而决定整行的去留。
filterAllRemaining(): 终止整个Scan。如果返回true，则整个扫描操作会立即停止。这在某些场景下非常有用，比如你使用PageFilter进行分页，当取够一页数据后，就需要立即停止扫描，避免多余的I/O。

一个常见的误解是：认为设置了一个值范围过滤器，HBase就会像关系型数据库的索引一样，“精准定位”到数据块。实际上，HBase的过滤器更多是“流式过滤”。它依赖于扫描的顺序性（按RowKey字典序），在遍历数据的过程中进行判断。因此，过滤器的效率，与RowKey的设计、扫描的范围紧密相关。如果你用过滤器去查一个散列的、非前缀匹配的RowKey，效果会很差，因为它几乎要扫描全表。

2.3 过滤器执行的位置：Scan与Get的差异

很多人知道Get是点查，Scan是范围查，但过滤器在两者上的执行有细微差别。

Scan with Filter：如上所述，是流式、逐KeyValue的过滤过程。
Get with Filter：Get本质上是对一个或多个明确RowKey的查询。当Get操作带上过滤器时，HBase会先根据RowKey定位到对应的Region和行，将该行的所有KeyValue（或根据Column指定范围）读取出来，然后在内存中应用过滤器进行筛选，最后将结果返回。对于Get，过滤器主要起到在客户端接收前对单行数据进行列级筛选的作用，其“服务端下推”减少网络传输的意义对于单行来说依然存在，但“跳过整行”的优化意义不大。

注意：虽然过滤器在服务端执行，但它并不是“免费”的。复杂的过滤器逻辑、尤其是需要解析大Value的过滤器（如SingleColumnValueFilter对长字符串进行正则匹配），会消耗RegionServer的CPU资源。在设计时，需要在“减少网络传输”和“增加服务端计算”之间做好权衡。对于超高频查询，有时在客户端做轻量过滤，或结合布隆过滤器（Bloom Filter）等结构，可能是更全局的优化。

3. 单值过滤器深度解析：不止是“等于”和“范围”

官方文档列出了十几种过滤器，我们将其分为几类来理解。首先是最常用、也最易误解的单值过滤器。

3.1 SingleColumnValueFilter：功能强大但开销昂贵

这是使用率最高，也最容易引发性能问题的过滤器。它允许你对某一特定列的值进行条件判断。

SingleColumnValueFilter filter = new SingleColumnValueFilter( Bytes.toBytes("cf"), Bytes.toBytes("status"), CompareOperator.EQUAL, Bytes.toBytes("ACTIVE") ); filter.setFilterIfMissing(true); // 如果该列不存在，则过滤掉整行 scan.setFilter(filter);

核心参数与行为：

CompareOperator: 支持EQUAL,NOT_EQUAL,GREATER,GREATER_OR_EQUAL,LESS,LESS_OR_EQUAL,NO_OP（总是包含）等。
setFilterIfMissing(boolean): 这是关键。如果为true，当被查询的列在该行中根本不存在时，过滤器会直接过滤掉整行。如果为false，则缺少该列的行会被包含在结果中。你必须根据业务语义明确设置这个值，默认是false，但这可能不是你想要的。
setLatestVersionOnly(boolean): 默认为true，只比较最新版本的值。如果设为false，则会检查该列的所有版本，只要有一个版本满足条件，该行就会被包含。

性能陷阱：SingleColumnValueFilter在执行时，需要从磁盘或缓存中读出指定列的完整Value值到内存，然后进行字节数组的比较。如果Value很大（比如存储了JSON或文本），这个操作的成本会很高。更糟糕的是，如果该列在表中并不稠密（很多行没有这个列），但你又设置了setFilterIfMissing(false)，扫描器仍然需要为每一行去尝试定位这个列，带来额外的开销。

实战建议：

避免对大Value列使用：如果要对大文本、二进制对象进行过滤，考虑将其指纹（如MD5）、分类ID等小数据单独存为一列，对该小数列进行过滤。
与RowKey设计结合：如果status=ACTIVE是一个高频过滤条件，能否将ACTIVE作为RowKey的一部分（例如{shardId}{userId}{status}）？这样可以直接通过RowKey前缀或范围进行扫描，完全跳过过滤器，效率最高。
明确setFilterIfMissing：仔细思考业务逻辑，避免因默认值导致查询结果错误。

3.2 ColumnValueComparator与RegexStringComparator：慎用的高级匹配

SingleColumnValueFilter可以与各种Comparator搭配，实现复杂匹配。

RegexStringComparator（正则比较器）：
```
SingleColumnValueFilter filter = new SingleColumnValueFilter( Bytes.toBytes("cf"), Bytes.toBytes("email"), CompareOperator.EQUAL, new RegexStringComparator(".*@company\\.com$") );
```
警告：这是性能杀手！正则表达式匹配计算密集，且无法利用任何优化。除非数据量很小或查询频率极低，否则应绝对避免在服务端使用正则过滤器。替代方案是在摄入数据时，将匹配结果（如域名）作为单独的列写入，或者将数据导出到Hive/Spark等计算引擎中进行批处理。

BinaryPrefixComparator（二进制前缀比较器）：

// 匹配以特定字节开头的Value SingleColumnValueFilter filter = new SingleColumnValueFilter( Bytes.toBytes("cf"), Bytes.toBytes("tags"), CompareOperator.EQUAL, new BinaryPrefixComparator(Bytes.toBytes("sys_")) // 匹配以"sys_"开头的值 );

这个比较器相对高效，因为它只需要比较Value的前几个字节。适用于对具有固定前缀的编码值进行过滤。

3.3 ValueFilter与QualifierFilter：灵活但需知其所以然

这两个过滤器提供了更基础的过滤维度。

ValueFilter：基于Cell的Value进行过滤，不关心具体是哪一列。
```
// 找出所有Value大于100的Cell（任何列） ValueFilter filter = new ValueFilter( CompareOperator.GREATER, new BinaryComparator(Bytes.toBytes(100L)) );
```
这非常灵活，但代价是需要检查每一行每一列的每一个Value，性能开销极大，仅适用于列很少或数据量很小的特殊场景。
QualifierFilter：基于列名（Qualifier）进行过滤。
```
// 找出列名以“metric_”开头的所有列 QualifierFilter filter = new QualifierFilter( CompareOperator.EQUAL, new BinaryPrefixComparator(Bytes.toBytes("metric_")) );
```
这在动态列（Dynamic Columns）场景下很有用，例如从海量指标列中筛选出某一组。它的效率取决于列名的分布和比较器的复杂度。

使用原则：始终问自己，过滤条件能否通过更高效的方式实现？比如，用ColumnPrefixFilter（下一节介绍）通常比用QualifierFilter加BinaryPrefixComparator更优，因为前者是专门为列名前缀过滤优化的。

4. 结构过滤器：高效筛选行列的利器

这类过滤器不关心具体的值，而是关注行、列的结构，通常性能更好。

4.1 PrefixFilter与ColumnPrefixFilter：RowKey与列名的前缀匹配

PrefixFilter：这是最常用、最高效的过滤器之一，用于RowKey前缀扫描。
```
// 扫描所有RowKey以“USER_20240501_”开头的行 PrefixFilter rowFilter = new PrefixFilter(Bytes.toBytes("USER_20240501_")); scan.setFilter(rowFilter);
```
HBase的数据按RowKey有序存储。PrefixFilter可以高效地利用这个有序性，快速定位到数据块的起始位置，并只扫描相关区域。这是实现数据分片（Sharding）查询的标准模式。例如，RowKey设计为{hash(userId)}{userId}{timestamp}，那么通过PrefixFilter指定{hash(userId)}就能快速定位到目标分区。
ColumnPrefixFilter：用于筛选具有特定前缀的列。
```
// 只获取列名以“attr_”开头的列 ColumnPrefixFilter colFilter = new ColumnPrefixFilter(Bytes.toBytes("attr_")); scan.setFilter(colFilter);
```
在宽表设计中，我们经常将不同属性存储为动态列（如attr_name,attr_age）。使用ColumnPrefixFilter可以一次性取出所有属性列，非常方便。它的实现同样利用了列名在存储中的局部有序性，效率较高。

4.2 MultipleColumnPrefixFilter与ColumnRangeFilter：多列与列范围筛选

MultipleColumnPrefixFilter：这是ColumnPrefixFilter的扩展，允许指定多个列名前缀。
```
byte[][] prefixes = new byte[][] { Bytes.toBytes("name"), Bytes.toBytes("email"), Bytes.toBytes("phone") }; MultipleColumnPrefixFilter filter = new MultipleColumnPrefixFilter(prefixes);
```
这在需要精确选取多个已知列族的特定列时非常有用，避免了返回不必要的数据。
ColumnRangeFilter：在列名有序的前提下，筛选一个列名范围内的所有列。这在时间序列数据中特别有用，例如列名是时间戳。
```
// 获取列名在[startTs, endTs)范围内的所有列 ColumnRangeFilter filter = new ColumnRangeFilter( Bytes.toBytes(startTs), // inclusive true, Bytes.toBytes(endTs), // exclusive false );
```
注意：ColumnRangeFilter的效率高度依赖于列名的有序存储。如果列名是散列的，效果会大打折扣。

4.3 KeyOnlyFilter与FirstKeyOnlyFilter：元数据扫描优化

这类过滤器用于只需要Key，不需要Value的场景，能极大减少网络传输。

KeyOnlyFilter：只返回每个KeyValue的Key部分（RowKey, Family, Qualifier, Timestamp），Value部分被设置为空字节数组。适用于统计行数、列数等元数据操作。
FirstKeyOnlyFilter：对于每一行，只返回第一个KeyValue（通常是按列排序的第一个）。这是实现高效行数统计（Count）的经典技巧。因为HBase没有原生的COUNT(*)，你可以通过FirstKeyOnlyFilter+ 客户端计数来近似实现，比全表扫描快几个数量级。
```
scan.setFilter(new FirstKeyOnlyFilter()); // 客户端遍历Result，每得到一个Result就计数+1
```

4.4 InclusiveStopFilter与PageFilter：控制扫描边界与分页

InclusiveStopFilter：HBase默认的Scan是左闭右开区间[startRow, stopRow)。如果你需要包含stopRow，可以设置scan.withStopRow(stopRow)并使用InclusiveStopFilter。
```
scan.withStartRow(startRow).withStopRow(stopRow); // stopRow本身不会被包含 scan.setFilter(new InclusiveStopFilter(stopRow)); // 现在stopRow会被包含
```
注意：startRow总是包含的，没有ExclusiveStartFilter。
PageFilter：用于客户端分页。但请注意，这是一个“服务器端限制”，而非“逻辑分页”。
```
// 第一页 PageFilter pageFilter = new PageFilter(100); scan.setFilter(pageFilter); // ... 执行scan // 获取最后一行的RowKey byte[] lastRowKeyOfPage = ...; // 下一页的Scan，startRow设置为上一页最后一条的RowKey + ‘\0’ (或下一个有效的RowKey) Scan nextPageScan = new Scan(); nextPageScan.withStartRow(Bytes.add(lastRowKeyOfPage, new byte[]{0})); nextPageScan.setFilter(new PageFilter(100));
```
PageFilter的原理是，RegionServer在扫描时，数着返回的行数，一旦达到设定值，就调用filterAllRemaining()终止扫描。它不保证返回正好100行，因为如果某一行被其他过滤器（如SingleColumnValueFilter）过滤掉了，它不会被计数，扫描会继续。因此，PageFilter通常需要与其他过滤器组合使用，并且分页逻辑需要客户端小心处理边界。

5. 过滤器组合与执行顺序：用FilterList构建复杂查询

现实中的查询条件往往是多个过滤条件的组合。HBase提供了FilterList来管理多个过滤器。

5.1 FilterList的逻辑：MUST_PASS_ALL 与 MUST_PASS_ONE

FilterList接受一个Operator参数，定义组合逻辑：

FilterList.Operator.MUST_PASS_ALL：逻辑与（AND）。一行数据必须通过列表中的所有过滤器才会被返回。
FilterList.Operator.MUST_PASS_ONE：逻辑或（OR）。一行数据只要通过列表中的任意一个过滤器就会被返回。

FilterList filterList = new FilterList(FilterList.Operator.MUST_PASS_ALL); // 条件1: RowKey以"ORDER_"开头 PrefixFilter prefixFilter = new PrefixFilter(Bytes.toBytes("ORDER_")); filterList.addFilter(prefixFilter); // 条件2: 状态为“SHIPPED” SingleColumnValueFilter statusFilter = new SingleColumnValueFilter( Bytes.toBytes("info"), Bytes.toBytes("status"), CompareOperator.EQUAL, Bytes.toBytes("SHIPPED") ); statusFilter.setFilterIfMissing(true); filterList.addFilter(statusFilter); // 条件3: 只取最新版本，且只要Key filterList.addFilter(new FirstKeyOnlyFilter()); scan.setFilter(filterList);

5.2 执行顺序与短路优化

FilterList中的过滤器按添加顺序依次执行。对于MUST_PASS_ALL，一旦某个过滤器判定跳过该行或该Cell，后续过滤器可能就不会再被评估（短路优化）。因此，将最廉价、过滤性最强的过滤器放在前面，能显著提升性能。

例如，上面的例子中，PrefixFilter成本极低且能快速过滤大量无关RowKey，放在第一位是明智的。FirstKeyOnlyFilter放在最后，因为它不改变数据内容，只做最后的结果转换。

一个重要的陷阱：MUST_PASS_ONE（OR）的逻辑在HBase中实现成本较高。因为每个过滤器都需要独立判断，无法像AND那样容易短路。在可能的情况下，应尽量避免使用复杂的OR逻辑，或者考虑通过多次Scan（每个Scan对应OR的一个分支）在客户端合并结果，有时这样反而更高效。

5.3 组合过滤器的调试技巧

复杂的FilterList可能产生不符合预期的结果。调试时，可以：

逐层剥离：先只用第一个过滤器，看结果；然后加上第二个，观察变化。这是定位问题过滤器的有效方法。
关注filterIfMissing：在组合过滤器中，每个SingleColumnValueFilter的setFilterIfMissing设置会相互影响，需要仔细推敲整体逻辑。
使用while循环打印Filter决策：在自定义过滤器中（后续会讲），可以通过重写filterCell等方法并打印日志，来观察每个KeyValue被处理的过程。

6. 自定义过滤器：当内置能力无法满足时

尽管内置过滤器已经很强大，但总有特殊业务逻辑无法直接满足。这时，你可以编写自定义过滤器。

6.1 实现一个简单的自定义过滤器

假设我们需要一个过滤器：只保留那些在“tags”列中包含所有指定标签的行。这是一个多值匹配的AND逻辑。

public class TagsIncludeAllFilter extends FilterBase { private Set<byte[]> requiredTags; private SortedSet<byte[]> foundTagsInCurrentRow; private boolean rowDone = false; public TagsIncludeAllFilter(Set<byte[]> requiredTags) { this.requiredTags = requiredTags; } @Override public void reset() { // 每开始新的一行，重置状态 this.foundTagsInCurrentRow = new TreeSet<>(Bytes.BYTES_COMPARATOR); this.rowDone = false; super.reset(); } @Override public ReturnCode filterCell(Cell c) { // 如果该行已被判定为不需要，直接跳过后续Cell if (rowDone) { return ReturnCode.SKIP; } // 只检查列族为‘cf’，列限定符为‘tags’的Cell if (Bytes.equals(c.getFamilyArray(), c.getFamilyOffset(), c.getFamilyLength(), Bytes.toBytes("cf"), 0, Bytes.toBytes("cf").length) && Bytes.equals(c.getQualifierArray(), c.getQualifierOffset(), c.getQualifierLength(), Bytes.toBytes("tags"), 0, Bytes.toBytes("tags").length)) { // 假设tags列的值是用逗号分隔的标签字符串 String tagStr = Bytes.toString(c.getValueArray(), c.getValueOffset(), c.getValueLength()); String[] tags = tagStr.split(","); for (String tag : tags) { byte[] tagBytes = Bytes.toBytes(tag.trim()); // 如果这个标签是我们需要的，记录下来 for (byte[] required : requiredTags) { if (Bytes.equals(tagBytes, required)) { foundTagsInCurrentRow.add(tagBytes); break; } } } } // 继续处理该行的下一个Cell return ReturnCode.INCLUDE; } @Override public boolean filterRow() { // 当该行所有相关Cell处理完后，判断是否包含所有所需标签 rowDone = true; return foundTagsInCurrentRow.size() != requiredTags.size(); // 如果数量不等，过滤掉这行 } @Override public boolean hasFilterRow() { // 告诉框架，我们需要使用filterRow()方法 return true; } }

使用方式：

Set<byte[]> tags = new HashSet<>(); tags.add(Bytes.toBytes("urgent")); tags.add(Bytes.toBytes("processed")); scan.setFilter(new TagsIncludeAllFilter(tags));

6.2 自定义过滤器的性能考量与最佳实践

序列化：自定义过滤器必须实现Writable接口（HBase 1.x）或org.apache.hadoop.hbase.filter.Filter接口的序列化方法。确保所有成员变量都能被正确序列化和反序列化，否则过滤器无法被发送到RegionServer。
状态管理：reset()方法至关重要。它会在开始扫描每一行时被调用，用于清理上一行的状态。上面的foundTagsInCurrentRow和rowDone必须在reset()中初始化。
避免复杂操作：filterCell方法会被调用非常频繁，务必保持其逻辑简单高效。避免在其中有复杂的字符串解析、正则匹配或对象创建。上面的例子中在filterCell里做字符串分割其实已经算重操作了，更好的设计是将标签存储为多列（如tag:urgent,tag:processed），然后使用MultipleColumnPrefixFilter或FilterList来实现AND逻辑。
使用filterRowKey进行早期过滤：如果过滤条件可以仅通过RowKey判断，重写filterRowKey(byte[] buffer, int offset, int length)方法。这个方法在读取行键时立即调用，如果返回true，则可以跳过整行数据，这是最高效的过滤。
单元测试：为自定义过滤器编写全面的单元测试，模拟不同的数据排列和边界情况（如列缺失、空值等）。

7. 过滤器实战避坑指南与性能调优

结合我踩过的坑，这里总结几个关键的性能陷阱和优化建议。

7.1 陷阱一：在Scan中盲目使用过滤器替代合理的RowKey设计

这是最常见的反模式。比如，有一张用户事件表，业务需要频繁查询某个用户某段时间的事件。如果RowKey设计成随机散列（如UUID），然后使用SingleColumnValueFilter去过滤user_id和time_range，性能将是灾难性的。因为扫描器需要遍历全表（或很大范围）的每一行，去检查这两列的值。

正确做法：将查询模式设计进RowKey。例如，RowKey设计为{userId反转}{timestamp}，这样查询特定用户一段时间的数据，就可以通过startRow和stopRow精准定位，可能完全不需要过滤器，或者只需要一个轻量的PrefixFilter。

原则：能用RowKey/StartRow/StopRow解决的问题，绝不用过滤器。过滤器是第二选择。

7.2 陷阱二：忽略过滤器的服务端成本

认为过滤器在服务端执行就是“免费午餐”。实际上，像ValueFilter、带RegexStringComparator的过滤器，会对每个Cell的Value进行全量检查和计算，消耗大量CPU。在RegionServer监控上，你可能会看到CPU使用率飙升，而网络I/O下降不多。

排查与优化：

监控RegionServer的CPU：如果使用过滤器后CPU显著升高，需要审查过滤器逻辑。
使用更高效的比较器：BinaryComparator比RegexStringComparator快几个数量级。BinaryPrefixComparator又比BinaryComparator快。
考虑客户端过滤：对于非常复杂的过滤逻辑，如果数据量经过其他条件（如RowKey范围）筛选后已经不大，可以将其拉到客户端过滤。这相当于将计算压力从服务端转移到了客户端，需要权衡客户端数量和服务端负载。

7.3 陷阱三：分页查询的误区

使用PageFilter进行分页时，常见的错误是直接用它来做“跳页”查询。例如，想取第101-200条记录，于是设置PageFilter(200)，然后在客户端丢弃前100条。这会导致服务端扫描并过滤了200条数据，但网络传输和客户端处理了200条，前100条被白白浪费和丢弃。

正确的分页模式：

记住上一页的最后一条RowKey：每次查询，除了使用PageFilter(pageSize)，更重要的是记录返回结果中最后一条数据的RowKey。
作为下一页的StartRow：下一次查询时，将StartRow设置为上次获取的最后一条RowKey的“下一个”RowKey。由于HBase行键是字典序排列，你可以通过在这个RowKey后追加一个0x00字节，或者根据业务逻辑计算出下一个合法的起始RowKey。
避免使用Offset：HBase没有SQL中的LIMIT 100 OFFSET 1000这种高效跳页机制。大偏移量的分页必然导致大量浪费。如果业务必须支持随机跳页，需要考虑其他方案，如将查询结果索引到Elasticsearch等支持高效分页的系统中。

7.4 陷阱四：过滤器组合导致的逻辑错误

当FilterList中包含多个SingleColumnValueFilter且设置为MUST_PASS_ALL时，如果某一行缺少其中某个列，而该过滤器的setFilterIfMissing又设置为false（默认），那么这一行可能会被意外地包含进来，因为“列缺失”不被视为“不满足条件”。这很可能违背了业务上“AND”的语义。

解决方案：仔细检查每个SingleColumnValueFilter的setFilterIfMissing。在大多数“AND”逻辑下，如果某列是必须存在的条件，应该将其设为true。更好的做法是，在数据模型设计时，就保证核心查询条件对应的列总是存在的（即使值为空或默认值），这样可以避免复杂的逻辑处理。

7.5 性能调优 checklist

RowKey设计优先：查询模式是否已最大程度体现在RowKey中？
扫描范围最小化：startRow和stopRow是否已设到最紧？
选择最轻量过滤器：能否用PrefixFilter、ColumnPrefixFilter替代ValueFilter或复杂的SingleColumnValueFilter？
过滤器顺序优化：在FilterList中，是否把过滤性最强、计算成本最低的过滤器放在最前面？
避免服务端复杂计算：是否使用了正则表达式？能否在数据写入时提前计算好标记位？
合理设置缓存：scan.setCaching(int)设置每次RPC返回的行数。设置太小会增加RPC次数，太大会占用客户端更多内存。根据单行数据大小和网络延迟进行调整，通常在几十到几百之间。
批量处理：对于大量查询，考虑使用Table.get(List<Get>)进行批量Get，这比循环执行单个Get效率高得多。同样，Scan也可以配合ResultScanner进行批量迭代。
监控与度量：关注RegionServer的监控指标，如TotalFilteredReadRequests、FilteredReadRequestsRate，以及Scan操作的平均响应时间。