Elasticsearch给布尔字段加用户ID前缀提升性能是否过度？

我有一个存储用户物品的Elasticsearch索引，部分字段为布尔类型，示例文档如下：

{
  "user_id": "123",
  "yellow": true,
  "new": false,
}

所有查询都会附带用户ID，比如典型查询条件是user_id=123 且 yellow=true。一位已无法联系的前同事建议：

低基数字段（如布尔型）在Elasticsearch中表现很差。ES没有高效的连接操作。对这类字段的过滤会返回所有符合条件文档的位域，再与其他过滤条件求交集。

理论上这似乎合理：ES会将yellow:true索引为所有用户的相关物品列表，查询时需要将用户123的物品集合与这个庞大集合求交集得到结果。因此我们尝试将所有布尔字段值加上用户ID前缀，改为关键词匹配，修改后的文档示例：

{
  "user_id": "123",
  "yellow": "123_true",
  "new": "123_false",
}

我不确定这种做法是否合理，是否属于过度优化？搜索了一小时未找到相关依据，对此持怀疑态度。

结论：这种做法属于过度优化，甚至是反向优化，完全没必要 #

1. 前同事的说法存在核心误区

Elasticsearch的查询优化器会自动选择基数更低的条件作为过滤入口。你的查询始终附带user_id，而每个user_id对应的物品数量远小于全局yellow:true的物品数量——ES会优先用user_id:123过滤出该用户的所有物品，再在这个极小的集合里匹配yellow:true，根本不会出现“先拉取全局布尔匹配集合再求交集”的情况。低基数字段本身不是性能瓶颈，关键看过滤条件的组合逻辑和基数对比。

2. 修改方案的弊端

• 存储成本上升：布尔类型仅占1位存储空间，改成123_true这类字符串后，存储空间会翻倍甚至更多，用户ID越长开销越大。
• 写入复杂度提升：每次写入或更新文档时，都要手动拼接用户ID和布尔值，增加代码维护成本，还容易出现拼接错误。
• 无性能收益甚至更慢：原布尔字段的匹配是极高效的位运算，改成字符串关键词匹配后，反而会增加ES的处理开销。

3. 正确的优化方向

保留原布尔字段设计即可，同时可以做以下优化确保性能：

• 确保user_id字段为keyword类型，保证精确匹配的效率。
• 查询时使用filter上下文（而非query上下文），ES会自动缓存过滤结果，大幅提升重复查询的响应速度。
• 如果用户物品数量极大，可以将同一个用户的文档路由到同一个分片（通过routing参数），减少查询时需要扫描的分片数量。

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