IDX.QUERY
查询索引：区间 / 等值、文本 MATCH、向量 KNN、聚合分组，或跨两个索引的 COMPOSE。
IDX.QUERY name RANGE min max [LIMIT n] [CURSOR c] [FIELDS field ...] | name EQ value [LIMIT n] [CURSOR c] [FIELDS field ...] | name MATCH text [LIMIT n] [FIELDS field ...] | name KNN vector [LIMIT k] [EF ef] [FIELDS field ...] | name GROUP group | name GROUPS [BY count|sum|min|max] [LIMIT n] | HYBRID text_idx MATCH text ann_idx KNN vector [LIMIT n] [RRFK k] [EF ef] [FIELDS field ...] | COMPOSE AND|OR nameA RANGE min max|EQ value nameB RANGE min max|EQ value [LIMIT n] [CURSOR c] [FIELDS field ...]复杂度
取决于索引种类。range：O(log N + limit)。unique：O(log N + hits)。全文：O(各倒排表长度之和)，带 MaxScore 剪枝。向量 ANN：O(dim * (M log N + ef * M)) 次距离计算（HNSW）。agg GROUPS：有界的 top-K，1 到 3 轮扇出。HYBRID：两个子查询各按 4 倍深度取，再在发起端用 RRF 融合。COMPOSE：不受 limit 约束 —— 两侧叶子都要完整物化，因为结果是按 key 排序的，而 segment 是按 value 排序的。
复杂度与兼容性是从 kevy 的实现里读出来的，不是抄 Redis 的文档。有几条确实不一样 —— 它们看起来像笔误，但不是。
与 Redis 的兼容性
kevy 独有
kevy 独有：最接近的是 RediSearch 的 FT.SEARCH —— 在两条轴上确实可比（我们的文本索引是倒排段上的 BM25，向量索引是 HNSW，RediSearch 两者都有）。差异在于：没有独立模块，也没有独立的索引服务；我们的 BM25 统计是按 shard 算的，不是全局的；查询面是一套固定语法，不是 DSL —— 没有字段加权，没有短语与邻近搜索，没有词干还原，也没有聚合管线。
另见
IDX.COUNTIDX.CREATEIDX.DROPIDX.EXPLAINIDX.LISTIDX.REBUILDIDX.VERIFY