wildcard 与 prefix 是什么
两者都属于「按模式匹配词条」的查询：wildcard 支持 * 匹配任意多个字符、? 匹配单个字符，prefix 只匹配前缀。它们作用在倒排索引的词条层面——对 keyword 字段匹配整串值，对 text 字段匹配分析后的单个词条，因此匹配范围与直觉里的模糊查找并不一样。
基本信息
| 通配符 | * 匹配任意多个字符，? 匹配单个字符，仅 wildcard 支持 |
|---|---|
| prefix 查询 | 只匹配词条前缀，效果等价于 ki* 但成本更低 |
| 大小写 | 默认区分，wildcard 可用 case_insensitive 放宽 |
| 作用层面 | 倒排索引词条：keyword 匹配整串，text 匹配单个词条 |
| 代价 | 前导通配要遍历大量词条，前缀匹配可利用词条前缀索引 |
典型使用场景
- 按编号前缀筛选资源：资源 ID、工单号、订单号类字段
- 辅助查找：只记得字符串的一部分时做辅助定位
- 日志检索：按模块名或路径前缀过滤
- 数据清理前定位：找出符合某命名规则的文档
- 作为过渡方案：在补建 n-gram 字段或前缀索引之前先临时用通配查询
常用写法
常用写法
# wildcard：* 任意多字符、? 单字符，默认区分大小写
GET /my-index/_search
{ "query": { "wildcard": { "user.id": { "value": "ki*y", "case_insensitive": true } } } }
# prefix：只匹配前缀，成本低于等价通配
GET /my-index/_search
{ "query": { "prefix": { "user.id": { "value": "ki" } } } }
# 纯过滤场景用 constant_score 包一层，跳过评分开销
GET /my-index/_search
{ "query": { "constant_score": { "filter": { "prefix": { "user.id": "ki" } } } } }
# 先看字段被分析成了哪些词条，确认通配到底作用在什么上
GET /my-index/_analyze
{ "field": "user.id", "text": "kitty" }匹配面与代价
| 写法 | 匹配对象 | 代价 |
|---|---|---|
| prefix: ki | 以 ki 开头的词条 | 低，可利用词条前缀索引 |
| wildcard: ki*y | 以 ki 开头、以 y 结尾的词条 | 中等，前导通配时明显升高 |
| wildcard: *ki | 任意以 ki 结尾的词条 | 高，需要遍历全部词条 |
| text 字段上的 wildcard | 单个词条内部匹配 | 跨词的整句模式永远不会命中 |
以 * 开头的模式要遍历大量词条，索引词条量级大时容易拖慢集群；能用前缀匹配、n-gram 字段或 keyword 精确匹配替代时，不要使用前导通配。
wildcard 的 rewrite 参数会影响评分行为与性能，纯过滤场景用 constant_score 包一层可以跳过评分计算，也更容易命中查询缓存。