distinct在mongodb事务中被硬性禁止，因其不支持snapshot隔离且会触发独立扫描与内存去重；事务外执行虽可行但性能差，主因是全量提取字段值哈希去重，易致内存压力；推荐用aggregate+$group替代，并启用allowdiskuse和复合索引优化。
distinct 在事务中为什么不能用
因为 distinct 命令本身不支持在 MongoDB 事务中执行——它会直接报错 CommandNotSupported: distinct is not supported in transactions。这不是性能瓶颈，而是硬性限制。MongoDB 官方明确禁止在事务上下文中调用 distinct、count、mapReduce、$merge、$out 等聚合副作用操作。
- 事务只允许读写操作（
find、insertOne、updateMany等），且所有读必须基于同一 snapshot -
distinct内部会触发独立的扫描 + 内存去重（类似$group），无法纳入事务的 snapshot 隔离机制 - 即使绕过驱动强行发命令，WiredTiger 层也会在事务会话校验阶段拒绝
事务外 distinct 的内存排序开销从哪来
事务外的 distinct 虽然能跑通，但性能差的核心原因是：它必须把所有匹配文档的指定字段值全拉到内存里做哈希去重，而不是靠索引直接返回唯一键。即使 {userid: 1} 有索引，distinct("region", {userid: "张三"}) 仍需遍历全部 100w 条匹配文档，逐个提取 region 值，再塞进内存哈希表。
- explain 输出里的
nReturned和totalDocsExamined通常相等，说明不是索引跳扫，而是“索引定位 + 全结果集提取” - 如果
region字段没建索引，情况更糟：连索引定位都失效，退化为 COLLSCAN - 内存压力来自哈希表本身——100w 个字符串平均 10 字节，光 key 就占 ~10MB，加上哈希桶和 GC 开销，容易触发 wiredTiger cache 挤出或 OS swap
替代方案：用 aggregate + $group 模拟 distinct 并控制资源
虽然 distinct 不能进事务，但 aggregate 管道中的 $group 可以（只要不带 $out 或 $merge）。更重要的是，它支持 allowDiskUse: true 和显式 maxTimeMS，能规避内存爆炸风险。
例如替代 db.usertable.distinct("region", {userid:"张三"})：
db.usertable.aggregate([
{ $match: { userid: "张三" } },
{ $group: { _id: "$region" } },
{ $project: { _id: 0, region: "$_id" } }
], {
allowDiskUse: true,
maxTimeMS: 15000
})
-
allowDiskUse: true允许$group在内存不足时写临时文件，避免 OOM - 复合索引
{userid: 1, region: 1}可让$match+$group走索引覆盖（IXSCAN only，不 fetch doc），大幅降低 CPU 和内存压力 - 注意：
$group结果默认无序，如需排序要加$sort，但会额外消耗内存
真正该警惕的隐形瓶颈：事务内嵌套 distinct 的误用尝试
有人试图在事务里先 find 出一批文档，再用 Python/Node.js 在应用层做 set 去重——这看似绕开了限制，实则更危险：它把事务锁持有时间延长到网络 + 应用处理完成，极易触发 TransactionTooOld；同时丧失了数据库层的原子性保障。
更稳妥的做法是：把去重逻辑前置到写入时（如用唯一索引约束）、或后置到异步任务（如用 change stream 捕获变更后更新汇总表），而非在事务边界内硬扛。
