RediSearch FT.SEARCH查询结果不一致及排序异常问题咨询

核心原因排查 #

1. 索引后台构建未完成 #

你数据库中有200w+前缀为chain-id.*的键，执行FT.CREATE后，RediSearch会异步后台构建索引，这个过程不会阻塞命令返回。在索引未完全构建完成时，多次查询会返回逐步增加的文档数，这就是两次查询匹配总数不一致的根本原因。

2. 时间字段类型配置错误 #

你将updatedAt定义为TEXT SORTABLE，字符串类型的排序是按字典序而非时间逻辑序。比如2022-11-13的字典序会比2022-12-01靠前（因为1在2前面），这就导致最新的2022-12-01数据无法排在查询结果前列，反而返回更早的日期数据。

3. 额外可能性验证 #

• 确认PREFIX 1 chain-id.的匹配规则：检查所有目标键是否严格以chain-id.开头，避免因拼写、大小写差异导致部分数据未被索引。
• 数据更新同步：如果索引创建后有数据更新，RediSearch默认会自动同步索引，但可通过FT.INFO查看hash_indexing_failures字段是否有异常。

修复步骤 #

1. 等待索引构建完成
   执行FT.INFO chainIdIdx，查看indexing字段值：

   • 若为1：说明索引仍在后台构建，等待其变为0后再查询，此时文档总数会稳定。
   • 若需创建索引时阻塞等待构建完成（Redis 6.2+支持），可在FT.CREATE末尾添加WAIT 0参数（注意200w数据可能需要数分钟至数十分钟）。

2. 修正时间字段类型
   删除旧索引（FT.DROPINDEX chainIdIdx），重新创建时将updatedAt改为DATE或NUMERIC类型：

   • 若updated-at是ISO8601格式字符串（如2022-12-01T00:00:00Z）：

     FT.CREATE chainIdIdx ON JSON PREFIX 1 chain-id. SCHEMA $.message-ids.*.redis-routing-key AS routingkeys TAG $.updated-at AS updatedAt DATE SORTABLE
     

   • 若updated-at是时间戳数字：

     FT.CREATE chainIdIdx ON JSON PREFIX 1 chain-id. SCHEMA $.message-ids.*.redis-routing-key AS routingkeys TAG $.updated-at AS updatedAt NUMERIC SORTABLE
     

   重新构建索引后，SORTBY updatedAt DESC会按时间逻辑排序，最新数据会返回在前列。

3. 验证索引完整性
   索引构建完成后，执行FT.INFO chainIdIdx查看num_docs是否与实际chain-id.*键的数量一致（可通过SCAN 0 MATCH chain-id.* COUNT 1000估算总数），确保无数据遗漏。

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