Elasticsearch Completion Suggester忽略Index参数返回多索引结果求助

首先，咱们来拆解你遇到的几个核心问题：

1. 为什么响应里会出现其他索引（如.kibana_1）的错误？ #

你已经在请求参数里指定了index => $this->organisation_index，但仍然出现其他索引的失败信息，大概率是以下原因之一：

• 客户端默认配置覆盖了索引指定：检查你的Elasticsearch PHP客户端初始化代码，有没有设置setDefaultParams(['index' => '_all'])或者通配符索引（比如*）？如果有，这个默认配置会优先于你请求里的单个索引参数，导致ES查询所有索引。
• $this->organisation_index值不正确：确认这个变量是不是确实指向单个目标索引，有没有不小心写成了通配符（比如organisation_*）或者多个索引的逗号分隔字符串？

你可以先直接用curl测试目标索引的查询，排除PHP客户端的问题：

curl -X GET "your-es-host:9200/$your_organisation_index/_search" -H "Content-Type: application/json" -d '{
    "suggest": {
        "suggestions": {
            "prefix": "your-test-query",
            "completion": {
                "field": "suggest1",
                "fuzzy": {"fuzziness": 0},
                "skip_duplicates": "false",
                "size": 7
            }
        }
    }
}'

如果这个curl请求返回没有其他索引的错误，那问题肯定出在PHP客户端的配置上。

2. 多索引使用同名字段的Completion Suggester是否有问题？ #

完全没问题，但有两个前提：

• 如果你需要跨这些索引查询：确保所有目标索引的suggest1字段都配置了正确的Completion类型映射，否则就会出现类似.kibana_1的“no mapping found”错误，还会拖慢查询速度（因为ES要扫描无关索引的shard）。
• 如果你不需要跨索引查询：那就严格指定单个索引（或索引别名），彻底避免ES扫描无关索引，这也是提升性能的关键。

如果需要跨多个有统一suggest1字段的索引查询，推荐用索引别名把这些索引分组，比如创建一个all_suggest_indices的别名，然后查询这个别名，比直接写多个索引更易维护。

3. 如何明确指定索引（彻底解决跨索引问题） #

除了确保请求里的index参数正确，还要注意：

• 去掉客户端初始化时的默认索引配置：如果之前设置了setDefaultParams(['index' => '_all'])，直接移除这一行，或者在请求里明确指定index来覆盖（不过优先保证默认配置正确）。
• 使用索引别名替代硬编码索引名：如果后续有索引扩容或拆分，别名可以帮你避免修改代码。

比如修正后的PHP请求参数，确保index是明确的单个索引或别名：

$params_organisations = [
    'index' => 'your_exact_organisation_index', // 确保这里是单个索引或别名
    'body' => [
        "suggest" => [
            "suggestions" => [
                'prefix' => $request->q,
                "completion" => [
                    "field" => "suggest1",
                    "fuzzy" => ["fuzziness" => 0],
                    "skip_duplicates" => false, // 这里建议用布尔值而非字符串"false"
                    "size" => 7
                ]
            ]
        ]
    ]
];

另外注意：skip_duplicates参数应该传布尔值false，而不是字符串"false"，虽然ES可能会自动转换，但严格按照参数类型传值更稳妥。

4. 关于弃用的suggest端点 #

你说得对，Elasticsearch已经弃用了专门的_suggest端点，现在推荐的方式就是把suggest放在_search请求的body里，也就是你当前使用的方式，这个是完全正确的，不用考虑回到旧端点。

性能优化补充 #

解决了跨索引查询的问题后，那些失败的shard就会消失，性能自然会提升。另外还可以：

• 确保suggest1字段的映射启用了preserve_separators和preserve_position_increments（根据你的业务需求调整），优化自动补全的效率。
• 开启ES的request cache，针对重复的suggest查询可以直接返回缓存结果，减少shard的计算开销。

内容的提问来源于stack exchange，提问作者T. Altena