如何在MongoDB Atlas 4.2.15中对Legacy Java UUID实现Like模糊查询

结论 #

该需求完全可以实现，但你示例中直接对UUID字段执行正则匹配的写法无法生效，因为MongoDB中存储的Legacy Java UUID是BSON二进制类型（Subtype 0x03），并非字符串格式，正则无法直接匹配二进制内容。

实现方案 #

方案1：聚合查询转换字符串匹配（适合临时查询） #

MongoDB 4.2版本支持直接用$toString算子将二进制UUID转为标准带横杠的可读字符串，再通过正则匹配即可，示例代码如下：

db.store.aggregate([
  // 新增临时字段存储UUID的字符串格式
  {
    $addFields: {
      refstore_str: { $toString: "$refstore" }
    }
  },
  // 对临时字段执行正则模糊匹配
  {
    $match: {
      refstore_str: /.*076881b30100.*/
    }
  }
])

• 优点：无需修改现有数据结构，直接可查
• 缺点：无法命中索引，会触发全表扫描，仅适合小数据量场景或一次性临时查询，不适合生产环境高频调用。

方案2：预存UUID字符串加索引（适合生产高频查询） #

如果需要频繁执行这类模糊查询，推荐在写入数据时额外冗余存储UUID的字符串格式字段，再为该字段建立索引，性能提升明显：

1. 写入数据时同步冗余字符串字段：

db.store.insertOne({
  refstore: UUID('8418b678-0596-11ec-bbde-076881b30100'),
  refstore_str: '8418b678-0596-11ec-bbde-076881b30100',
  // 其他业务字段
})

2. 为字符串字段建立索引：

// 普通单值索引即可支持前缀匹配正则命中索引
db.store.createIndex({ refstore_str: 1 })

3. 执行查询：

// 若仅匹配后缀可以去掉开头的.*，如果是固定前缀匹配还能进一步优化索引效率
db.store.find({ refstore_str: /.*076881b30100/ })

如果你的模糊匹配片段是固定位置（比如固定匹配最后12位），还可以单独冗余存储该片段字段，索引体积更小，查询性能更高。

注意事项 #

MongoDB官方已适配Legacy Java UUID（Subtype 0x03）的字节序，$toString转换出来的字符串和Java侧生成的UUID字符串完全一致，不会出现字节序翻转导致的匹配错误问题。

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