我有一个视图，其中定义了 map 和 reduce 函数，并且在此视图中缩减和非缩减查询都很有用（这里最需要非缩减查询）。
当它重新索引少量 10k 文档时，CPU 会达到顶峰，并且需要很长时间才能建立完整索引。删除（或简化）reduce 函数解决了这个问题，并且在我可以看到的 couchjs 日志中，reduce/rereduce 调用消耗了所有资源。
问题是：为什么 couchdb 调用 reduce/rereduce 来构建索引，即使使用“reduce=false”选项查询视图？我认为不可能将这些值用作预先计算的，那么我做错了什么？
CouchDB Map/Reduce 索引总是完全预先计算并缓存在磁盘上；从磁盘索引满足查询。
这意味着在哪些方面运行良好存在一些限制，特别是在 reduce 函数中。一般的想法是你的reduce函数应该发出大小恒定的值/结构。这意味着如果您有一个 reduce() 函数来累积数据而不实际减少它（例如将 map 阶段的键或值连接到一个数组中，然后返回该数组），这是一个坏主意。通常，CouchDB 配置了query_server_config.reduce_limit设置为 true 的选项，以帮助防止您编写错误的 reduce 函数。