TiDB 6.5.1复合索引下TiKV扫描行为疑问及HTAP优化咨询

开发者阿泽

2026-7-25

TiKV扫描行为分析与HTAP表设计优化建议

一、TiKV扫描行为差异原因分析

基于复合索引(a,b)的有序性（先按a排序，a相同则按b排序），结合你的四个查询场景，差异原因如下：

场景1：select sum(c) from t where a=123 and b='simple' group by b
a=123是等值条件，能直接定位到索引中a=123的连续区间，再通过b='simple'进一步缩小范围，即使需要回表取c，扫描范围明确且可控，因此优化器选择范围扫描。
场景2：select sum(c) from t where a>=123 and b='simple' group by b
a>=123是范围条件，此时索引中a>=123的行对应的b值是无序的（不同a值下的b没有排序关系），优化器认为：遍历所有a>=123的索引行，再过滤b='simple'并回表取c的成本，高于直接全表扫描后过滤的成本（大表下这个估算偏差会导致性能问题），因此选择全表扫描。
场景3：select sum(a) from t where a>=123 and b='simple' group by b
聚合的a是索引列，无需回表，直接通过索引即可完成过滤和聚合，整体成本远低于全表扫描，因此优化器选择范围扫描索引。
场景4：select sum(c) from t where a>=123 group by a
与场景2逻辑一致：a>=123是范围条件，聚合c需要回表，优化器估算索引扫描+回表的成本高于全表扫描，因此选择全表扫描。

要确保左前缀范围（>=/<=/between等）搭配后续条件的查询触发索引扫描，核心是降低索引扫描的成本（减少回表或避免回表）：

创建覆盖索引：
- 针对场景2，创建索引(a,b,c)，这样sum(c)可直接从索引获取，无需回表，优化器会优先选择范围扫描索引。
- 针对场景4，创建索引(a,c)，聚合c无需回表，索引扫描成本低于全表扫描，优化器会自动选择范围扫描。
利用索引下推：确保TiDB开启索引下推（默认开启），TiKV层会先过滤b='simple'的条件，减少回表的数据量，降低整体扫描成本。
强制索引（临时方案）：如果优化器仍误判，可通过hint强制使用索引，例如：
```
select /*+ INDEX(t idx_a_b) */ sum(c) from t where a>=123 and b='simple' group by b;
```
注意：hint仅作为临时 workaround，长期建议通过覆盖索引让优化器自动选择最优计划。

结合HTAP的OLTP低延迟和OLAP高吞吐需求，优化方向如下：

列族拆分：将OLTP高频访问列（如a、b、c）和OLAP专属列（如历史明细、大字段）拆分到不同列族。OLTP操作仅访问热列族，减少IO开销；TiSpark可扫描全列族，不影响OLTP性能。
分区表设计：按范围查询的核心列（如a）或时间维度分区，OLTP仅操作最新分区，TiSpark可并行扫描多个分区，大幅提升分析效率。例如：
```
CREATE TABLE t (...) PARTITION BY RANGE (a) (
  PARTITION p0 VALUES LESS THAN (100),
  PARTITION p1 VALUES LESS THAN (200),
  ...
);
```
索引策略平衡：OLTP侧仅保留满足即席查询的必要复合索引，避免过多索引降低写入性能；TiSpark依赖列存特性，无需额外创建OLAP专属索引，优先通过列族和分区优化扫描效率。
数据类型优化：选择紧凑的数据类型，例如a用整数而非字符串，b设置合适的varchar长度，避免大字段拖慢索引和扫描速度；分析场景优先用固定长度类型，提升TiSpark的扫描吞吐量。
读写分离配置：配置TiSpark优先读取TiKV的Raft Learner副本，让OLAP分析请求与OLTP请求隔离，避免互相影响性能。
统计信息维护：定期执行ANALYZE TABLE t;更新TiDB统计信息，确保优化器能准确估算执行成本；TiSpark也依赖这些统计信息生成最优分析计划。

内容的提问来源于stack exchange，提问作者Ajay