我在某处提到过，emit(key, doc)做一个会增加索引构建的时间（或者那种效果）。
它是否有任何价值，是否有任何理由不总是emit(key, null)然后include_docs = true？
答案 0 :(得分：23)
是的，它会增加索引的大小，因为CouchDB在这些情况下有效地复制了整个文档。对于您可以使用的情况，请使用include_docs=true。
然而，在使用wiki中提到的时候，有一个竞争条件需要注意。在读取视图数据和获取文档之间的时间内，所述文档可能已更改（或已被删除，在这种情况下_deleted将为true）。这在“查询选项”下记录为here。
答案 1 :(得分：3)
这是一个经典的时间/空间权衡。
将文档数据发送到索引中会增加磁盘上索引文件的大小，因为CouchDB会将发出的数据直接包含在索引文件中。但是，这意味着，在查询数据时，CouchDB可以直接从磁盘上的索引文件中流式传输内容。这显然非常快。
依赖于include_docs=true将减少磁盘索引的大小，这是真的。但是，在查询时，CouchDB必须为每个返回的行执行文档读取。这主要涉及来自主数据文件的随机文档查找，这意味着返回数据的成本和时间显着增加。
虽然少量文档的查询时间差很慢，但它会超过应用程序的每次调用。因此，对我来说，从文档到索引中发出所需的字段通常是正确的调用 - 磁盘很便宜，用户的注意力不那么频繁。这大致类似于在关系数据库中使用覆盖索引，这是另一个广泛响应的建议。
我做了一个完全不科学的test on this来了解差异是什么。我发现，与文档直接发送到索引本身的视图相比，使用include_docs=true从视图中读取100,000个文档时，响应时间增加了8倍，CPU增加了50％。