我最近将一个 CloudSearch 实例从 2011 年升级到 2013 年的 API。两个实例都有一个名为 sid这是一个文本字段，包含一个两个字母的代码和一些数字，例如LC12345。使用2011年的API，如果我运行这样的搜索......我得到了一个结果，这很好。
q=12345*&return-fields=sid,name,desc
...我得到一个结果，这很好。但结果的侧面是 LC12345 而这是它的索引方式。数字12345 不 出现在生成的文档字段中的任何其他地方。我不明白为什么会这样。我只能假设这种类型的查询是在寻找任何字段中的任何术语，这些术语甚至是 包含 的数字12345。
我问这个问题的原因是，当我使用2013年的API查询时，这个功能现在已经被破坏了。我需要使用结构化查询解析器，但即使是使用简单的解析器进行类似的通配符查询，也无法正常工作，如
q.parser=simple&q=12345*&return=sid,name,desc
...什么也不返回，尽管文档肯定是存在的，例如，如果我查询的是 LC12345* 它能找到文档。
如果我能找出如何让简单查询像以前那样工作，那至少可以让我开始了解如何使用结构化语法进行同样的工作。
CloudSearch v1 (2011) 有一种不同的方式来标记 alpha+数字混合字符串。以下是归档的 文件 (强调是我的)。
如果一个字符串同时包含字母和数字字符，并且长度至少为3个字符，不超过9个字符，则该字符串的字母和数字部分将作为单独的标记处理。例如，字符串 DOC298 被标记为两个术语：doc 298
CloudSearch v2 (2013) 文本处理 随之 统一码文本分割，它没有规定这种行为。
不要在数字序列内或字母相邻的数字（"3a"，或 "A3"）中断开。
你应该可以搜索 *12345 得到任何前缀的结果。可能会有一些边缘情况，比如得到您不想要的结果（像AB99912345这样前面有更多数字的东西）；我对您的数据了解不够，无法判断这些是否是真正的问题。
另一个选择是将数字前缀与字母后缀分开索引，但这是额外的工作，可能没有必要。
我猜测你使用的是英文的Cloudsearch，所以也许这不是你的具体问题，但也要注意搜索查询中的Stopwords。
https:/docs.aws.amazon.comcloudsearchlatestdeveloperguideconfiguring-analysis-hemes.html#stopwords
在你的例子中，"jo "这个词在丹麦语和其他语言中是一个停顿词，当然，支持的语言也有一个停顿词的字典，里面有很常见的停顿词。如果你没有在文本字段中指定语言，它将是英语。你可以在这里看到它们。https:/docs.aws.amazon.comcloudsearchlatestdeveloperguidetext-processing.html#text-processing-settings。