KSQLDB Pull查询性能及RocksDB索引相关技术问询

核心查询逻辑与效率 #

• 主键精准查询：当Pull查询指定**主键（PRIMARY KEY）**进行精准匹配时，KSQLDB会直接依托RocksDB的键值存储特性，通过主键定位到对应分区的RocksDB实例，直接读取目标数据，不会触发全表扫描。这种场景下性能接近RocksDB原生键查询速度，KSQLDB仅做少量协议转换和格式适配，无多余扫描操作。
• 非主键/无索引查询（默认行为）：如果Pull查询未指定主键，或是使用了无法匹配索引的范围/过滤条件（比如WHERE age > 30且age无索引），默认会触发全表扫描——遍历所有分区的RocksDB表来匹配数据，性能随数据量增长显著下降。

索引利用与表扫描控制 #

• 二级索引的作用：若为表创建了二级索引（CREATE INDEX idx_user_id ON users(user_id);），当Pull查询的过滤条件命中索引键时，KSQLDB会自动使用该索引定位数据，避免全表扫描。比如查询WHERE user_id = 123就会走idx_user_id索引，而非扫描全表。
• 禁用全表扫描：可通过设置配置项ksql.query.pull.table.scan.enabled=false强制禁用全表扫描。此时若提交的Pull查询无法通过主键或二级索引定位数据，查询会直接失败，而非执行低效的全表扫描。

常见误区说明 #

并非所有Pull查询都直接走RocksDB键查询——只有当查询条件匹配主键或已创建的二级索引时，才会触发高效的键定位；无索引的过滤查询默认会走全表扫描，逻辑和传统关系型数据库类似。

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