The biggest performance lever in HBase is usually the row key, not the filter chain. Most of the issues below come back to that fact.
Let the row key do the routing
When a query can be expressed as a row key lookup, use it. HBase can then determine which server in the cluster holds the data with far less work. For a single-record read, Get is always the fastest option.
Reversed scans have constraints
Scan.setReversed(true) and Filter.setReversed(true) can return results in reverse order, but they are not a free switch. If you use Scan.setStartRow() and Scan.setStopRow() together with Scan.setReversed(true), the query can return no data. With a FilterList, every filter must use the same reversed flag; otherwise HBase reports an error: Filters in the list must have the same reversed flag, this.reversed=XXX.
Control batch size and result size
Scan.setBatch() limits the maximum number of Cells returned and helps prevent OutOfMemory. Do not confuse it with Scan.setMaxResultSize(): the latter sets a binary byte limit, not the number of records returned.
Paging, missing rows, and time ranges
PageFilter can be used for pagination, but it cannot provide the total number of records across all data. Filter.setFilterIfMissing() controls whether a row is skipped when the filtered column is missing. For timestamp-based queries, use Scan.setTimeRange().
Matching row keys with filters
SubstringComparator supports fuzzy matching. To apply a regex to the row key, use RowFilter with RegexStringComparator; for a row key prefix, use RowFilter with BinaryPrefixComparator.
Filters are not a substitute for row key design
Filter-based queries are much less efficient than row key lookups, and the gap becomes more obvious as data volume grows. A well-designed row key matters, and it is worth using as much of the row key as possible in the query.
Keep schema names compact
Column family names and row keys should be as short as practical. If one column family can handle the use case, do not split it into two: it wastes space and makes queries less convenient.
That covers the main pitfalls so far.