couchbase在使用特定索引时不返回某些文档

根据我所做的测试，这些文档似乎特别大（~2mb），当查询使用特定索引时（在我的例子中是数组索引）。
当文档变小时，它似乎工作正常。
这发生在Couchbase dashboard、cbq或我正在使用的scala SDK中。
我正在使用Couchbase 4.6.0和内存优化索引

---

我有以下与此查询相关的索引：

CREATE INDEX `cache_partial_specific`
ON `content`(`docType`,`entityType`,`entityId`) 
WHERE (`docType` = "feedCachePartial") WITH { "defer_build"=true }  

CREATE INDEX `feed_cache_partial_meta`
ON `content`(`meta().id`)
WHERE (`docType` = `feedCachePartial`)  

CREATE INDEX `cache_partial_index`
ON `content`((distinct (array (`url`.`id`) for `url` in `urls` end)))
WHERE (`docType` = "feedCachePartial") WITH { "defer_build"=true }

最后一个是制造麻烦的

---

问题是：

例如，在运行时

SELECT*FROM content WHERE meta（）.id='cached:topic:297:grp:all'

或

从docType='feedCachePartial'和entityId=297以及entityType='topic'的内容中选择*

它返回文档，我在列表中看到url 13319

但是跑步的时候

SELECT * FROM content
WHERE docType='feedCachePartial'
AND ANY url IN urls SATISFIES url.id = 13119 END

或条件的任何变化

url中的任何url满足url.id=13119

不会返回缓存的文档

topic:297:grp:all

---

max\u indexer\u doc\u size

被设置为20 MB，因此我认为这不是问题所在（无论采用哪种方法，在使用其他索引时都会返回它）

查看查询日志时，我看到我使用的这个特定索引有一个副本（我在这个集群上总共有3个索引节点）

---

---

我会调查这个索引，看看哪些文档会在索引上调整大小，但我不知道怎么做

好的，我在这里只做最简单的猜测，但是在这个查询中

SELECT * FROM content
where docType='feedCachePartial'
and meta().id = 'cached:topic:297:grp:all'
AND entityId=297
and entityType='topic'
AND ANY url IN c.urls SATISFIES url.id = 13119 END

---

“c.url”中的“c”是否正确？或者第一行是否应该说

SELECT*FROM content c

？

检查indexer.log，查看是否由于索引键大小限制而跳过了文档键的特定索引。如果索引未索引，则查询将找不到该文档。如果您已经知道文档键和查询没有包含，那么最好的选择是指定使用键并删除META（）。这样可以节省时间

由于您的文档很大，并且正在尝试进行数组索引，因此可能已跳过。如果知道文档键，则无需使用数组索引，直接使用USE键和apply谓词获取文档。如果由于大小限制而跳过文档，请检查此帖子

除非您在META（）.id（例如：META（）.id类似于“xyz%”）上进行搜索，否则feed\u cache\u partial\u元索引可能不会有用。你可以用钥匙

如果文档很小，您可以像这样组合其他索引，看看它是否有效并避免交叉扫描

CREATE INDEX `cache_partial_index`
ON `content`(`docType`,`entityType`,`entityId`, DISTINCT ARRAY url.id FOR url IN urls END)
WHERE (`docType` = "feedCachePartial") WITH { "defer_build"=true };

以下博客提供了有用的信息

---

不确定这是否相关，但我有点困惑，为什么您上次的查询会检查除文档键以外的任何内容。既然您知道键，为什么还要添加其他条件？您是否检查过问题是索引而不是查询？如果您只有主索引，查询是否会缓慢返回正确答案？此外，当您使用带有奇怪字符的名称时，您只需要返回勾号，如-+%$。我想你可以删除上面所有语句中的背面记号。@MatthewGroves这是一个印刷错误，我编辑了它。Thanks@JohanLarson“主要索引”指的是什么？我有3个与这个查询相关的GSI索引（url.id、meta（）.id、docType），它们都是不同的变体。只有当我在url.id上使用索引时，我才没有得到预期的结果。据我所知，我没有使用反勾号，我使用的是单引号。这是一个印刷错误，我现在用固定的QueryTank编辑了它。这确实是问题所在。您知道最大数组大小限制的原因吗？为什么它有一个专门针对阵列的限制？是因为阵列更可能消耗高RAM吗？我是否应该犹豫是否将其更改为更大的数字（例如1GB）？如果键大小更大，索引记录的大小也会更大，这会影响性能。您应该尝试最新版本的CB，该版本已放宽此限制。

CREATE INDEX `cache_partial_index`
ON `content`(`docType`,`entityType`,`entityId`, DISTINCT ARRAY url.id FOR url IN urls END)
WHERE (`docType` = "feedCachePartial") WITH { "defer_build"=true };