Elastic AppSearch/Enterprise Search如何实现字段仅存储不索引？

完全不需要通过错设geolocation、date类型的方式绕路，Elastic App Search有官方原生的支持能力，可以实现字段仅持久化存储、不构建检索索引的需求。

核心实现逻辑 #

App Search作为构建在Elasticsearch底层能力之上的检索层，所有引擎字段最终都会映射为底层ES索引的字段。针对不需要参与检索的业务字段，完全可以通过映射配置关闭字段的索引开关，达到仅存储的效果：

• 在引擎的底层自定义映射配置中，针对目标字段设置index: false参数。这个配置的作用是：不会为该字段构建倒排索引/空间索引/时间索引，因此字段本身不会出现在可检索、可筛选、可排序的字段列表里，也不会占用索引构建的计算资源；但字段的原始值会完整保留在文档的_source存储中，不会出现数据丢失的问题。
• 当通过其他可索引字段检索出对应文档时，只需要在App Search的返回结果配置中，把这类仅存储的字段加入返回字段列表，就可以正常拿到字段值返回给业务侧，完全匹配电商场景下内部备注、商品溯源信息、内部成本参数这类“不需要检索、但需要随结果返回”的字段需求。

为什么不推荐错设geolocation/date类型的绕行方案 #

这类操作本质是想靠类型错配规避默认的索引逻辑，实际根本达不到预期效果，还会引入一堆问题：

• 首先会触发严格的字段类型校验：如果字段实际值和配置的date/geolocation格式不匹配，写入时会直接报错，导致商品、订单这类核心业务数据的同步流程直接失败。
• 就算靠格式转换勉强写入成功，geolocation类型仍会构建地理空间索引、date类型仍会构建时间范围索引，根本达不到“不建立索引、不占用索引计算资源”的目标，反而会因为类型错配增加不必要的索引开销。
• 后续如果要调整字段配置，错误的类型绑定会导致字段值更新、映射调整的流程出现兼容性问题，排查和修复的成本远高于正规配置的成本。

配置注意事项 #

• 配置了index: false的字段，无法参与全文检索、分面筛选、结果排序的逻辑，配置前需要明确确认该字段没有任何检索类的业务需求。
• 涉及权限隔离、数据过滤的规则字段不能设置index: false，这类字段需要参与查询阶段的过滤逻辑，关闭索引后会导致权限校验、数据过滤功能失效。

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