数据存储查询不起作用,要求的索引比预期的多
Posted
技术标签:
【中文标题】数据存储查询不起作用,要求的索引比预期的多【英文标题】:Datastore query is not working, asking more index than expected 【发布时间】:2015-10-13 13:57:04 【问题描述】:<datastore-index kind="Environment" ancestor="false">
<property name="active" direction="asc" />
<property name="consumed" direction="asc" />
</datastore-index>
<datastore-index kind="Environment" ancestor="false">
<property name="active" direction="asc" />
<property name="creationDate" direction="desc" />
</datastore-index>
上面两个索引我都有
当我如下查询时,它不起作用,并且说需要新索引。
SELECT * FROM Environment
where active = false and consumed = true and creationDate < '2013-09-22'
GQL 响应如下:
没有找到匹配的索引。 此查询的建议索引是:
<datastore-index kind="Environment" ancestor="false">
<property name="active" direction="asc" />
<property name="consumed" direction="asc" />
<property name="creationDate" direction="asc" />
</datastore-index>
我做错了什么?不应该基于zigzag合并吗?
【问题讨论】:
【参考方案1】:在查看 zigzag 查询需要哪些索引时,将索引拆分为前缀和后缀非常有用。索引的前缀用于回答等式,后缀用于回答不等式和排序。
为了执行合并连接,查询中涉及的所有索引的后缀必须匹配,以便排序顺序相同。因此,对于您的查询:
SELECT * FROM Environment where active = false and consumed = true and creationDate < '2013-09-22'
creationDate
必须在后缀中; active
和 consumed
必须在前缀中。
索引:
<datastore-index kind="Environment" ancestor="false">
<property name="active" direction="asc" />
<property name="consumed" direction="asc" />
<property name="creationDate" direction="asc" />
</datastore-index>
如果我们将索引拆分为consumed
和creationDate
之间的前缀和后缀,就可以满足这个要求。但是,您也可以使用两个单独的索引来满足这一点:
<datastore-index kind="Environment" ancestor="false">
<property name="active" direction="asc" />
<property name="creationDate" direction="asc" />
</datastore-index>
<datastore-index kind="Environment" ancestor="false">
<property name="consumed" direction="asc" />
<property name="creationDate" direction="asc" />
</datastore-index>
在这种情况下,后缀将包含creationDate
,前缀将分别为active
和consumed
。请注意,在这种情况下,两个索引中的后缀如何匹配,这是执行 zigzag 合并连接的要求。
对于您当前拥有的索引,无法回答查询是因为
<datastore-index kind="Environment" ancestor="false">
<property name="active" direction="asc" />
<property name="consumed" direction="asc" />
</datastore-index>
没有creationDate
作为后缀。
【讨论】:
非常感谢。我明白了。 不用担心——如果这回答了你的问题,你能接受吗?这样其他有类似问题的人就知道这是正确的。以上是关于数据存储查询不起作用,要求的索引比预期的多的主要内容,如果未能解决你的问题,请参考以下文章
查询有 67156 行的索引 MySQL 表,检查 162880 行,索引不起作用吗?
MYSQL数据库表排序规则不一致导致联表查询,索引不起作用问题
QueryDSL 子查询不起作用 - IllegalArgumentException:参数值与预期类型不匹配