[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-20。"],[[["\u003cp\u003eEntities must have a value for every property named in a query's filters and sort orders to be included in the results, and it is not possible to specifically query for entities lacking a property.\u003c/p\u003e\n"],["\u003cp\u003eQueries cannot find or sort property values that are not indexed, and inequality filters are limited to a maximum of one property across all query filters.\u003c/p\u003e\n"],["\u003cp\u003eWhen no sort order is specified in a query, the order of results is undefined and may change, so specifying the desired sort order explicitly is recommended.\u003c/p\u003e\n"],["\u003cp\u003eQueries with equality filters for a given property will ignore any specified sort order for that property, potentially causing results to return in an order different from what the sort order implies.\u003c/p\u003e\n"],["\u003cp\u003eQueries within transactions must use ancestor filters to restrict operations to entities within the same entity group, and entities with multiple values can behave in unexpected ways with query filters and sort orders.\u003c/p\u003e\n"]]],[],null,["# Restrictions on queries\n\n| This API is supported for first-generation runtimes and can be used when [upgrading to corresponding second-generation runtimes](/appengine/docs/standard/\n| go\n| /services/access). If you are updating to the App Engine Go 1.12+ runtime, refer to the [migration guide](/appengine/migration-center/standard/migrate-to-second-gen/go-differences) to learn about your migration options for legacy bundled services.\n\nThis page covers the restrictions on querying Datastore from Google App Engine.\nThe following list are common restrictions that you'll run into when developing for\nDatastore.\n\nEntities lacking a property named in the query are ignored\n----------------------------------------------------------\n\nEntities of the same kind need not have the same properties. To be eligible as a query result, an entity must possess a value (possibly null) for every property named in the query's filters and sort orders. If not, the entity is omitted from the indexes used to execute the query and consequently will not be included in the query's results.\n| **Note:** It is not possible to query for entities that are specifically *lacking* a given property. One alternative is to filter on a field's zero value, then filter for entities with `null` as the value of that property.\n\nFiltering on unindexed properties returns no results\n----------------------------------------------------\n\nA query can't find property values that aren't indexed, nor can it sort on such properties.\n\nInequality filters are limited to at most one property\n------------------------------------------------------\n\nTo avoid having to scan the entire index, the query mechanism relies on all of a query's potential results being adjacent to one another in the index. To satisfy this constraint, a single query may not use inequality comparisons (`\u003c`, `\u003c=`, `\u003e`, `\u003e=`) on more than one property across all of its filters. For example, the following query is valid, because both inequality filters apply to the same property: \n\n q := datastore.NewQuery(\"Person\").\n \tFilter(\"BirthYear \u003e=\", minBirthYear).\n \tFilter(\"BirthYear \u003c=\", maxBirthYear)\n\nHowever, this query is *not* valid, because it uses inequality filters on two different properties: \n\n q := datastore.NewQuery(\"Person\").\n \tFilter(\"BirthYear \u003e=\", minBirthYear).\n \tFilter(\"Height \u003c=\", maxHeight) // ERROR\n\nNote that a query *can* combine equality (`=`) filters for different properties, along with one or more inequality filters on a single property. Thus the following *is* a valid query: \n\n q := datastore.NewQuery(\"Person\").\n \tFilter(\"LastName =\", targetLastName).\n \tFilter(\"City =\", targetCity).\n \tFilter(\"BirthYear \u003e=\", minBirthYear).\n \tFilter(\"BirthYear \u003c=\", maxBirthYear)\n\nOrdering of query results is undefined when no sort order is specified\n----------------------------------------------------------------------\n\nWhen a query does not specify a sort order, the results are returned in the order they are retrieved. As the Datastore implementation evolves (or if an application's indexes change), this order may change. Therefore, if your application requires its query results in a particular order, be sure to specify that sort order explicitly in the query.\n\nSort orders are ignored on properties with equality filters\n-----------------------------------------------------------\n\nQueries that include an equality filter for a given property ignore any sort order specified for that property. This is a simple optimization to save needless processing for single-valued properties, since all results have the same value for the property and so no further sorting is needed. Multiple-valued properties, however, may have additional values besides the one matched by the equality filter. Because this use case is rare and applying the sort order would be expensive and require extra indexes, the Datastore query planner simply ignores the sort order even in the multiple-valued case. This may cause query results to be returned in a different order than the sort order appears to imply.\n\nProperties used in inequality filters must be sorted first\n----------------------------------------------------------\n\nTo retrieve all results that match an inequality filter, a query scans the index for the first row matching the filter, then scans forward until it encounters a nonmatching row. For the consecutive rows to encompass the complete result set, they must be ordered by the property used in the inequality filter before any other properties. Thus if a query specifies one or more inequality filters along with one or more sort orders, the first sort order must refer to the same property named in the inequality filters. The following is a valid query: \n\n q := datastore.NewQuery(\"Person\").\n \tFilter(\"BirthYear \u003e=\", minBirthYear).\n \tOrder(\"BirthYear\").\n \tOrder(\"LastName\")\n\nThis query is *not* valid, because it doesn't sort on the property used in the inequality filter: \n\n q := datastore.NewQuery(\"Person\").\n \tFilter(\"BirthYear \u003e=\", minBirthYear).\n \tOrder(\"LastName\") // ERROR\n\nSimilarly, this query is not valid because the property used in the inequality filter is not the first one sorted: \n\n q := datastore.NewQuery(\"Person\").\n \tFilter(\"BirthYear \u003e=\", minBirthYear).\n \tOrder(\"LastName\").\n \tOrder(\"BirthYear\") // ERROR\n\nProperties with multiple values can behave in surprising ways\n-------------------------------------------------------------\n\nBecause of the way they're indexed, entities with multiple values for the same property can sometimes interact with query filters and sort orders in unexpected and surprising ways.\n\nIf a query has multiple inequality filters on a given property, an entity will match the query only if at least one of its individual values for the property satisfies *all* of the filters. For example, if an entity of kind `Widget` has values `1` and `2` for property `x`, it will *not* match the query: \n\n q := datastore.NewQuery(\"Widget\").\n \tFilter(\"x \u003e\", 1).\n \tFilter(\"x \u003c\", 2)\n\nEach of the entity's `x` values satisfies one of the filters, but neither single value satisfies both. Note that this does not apply to equality filters. For example, the same entity *will* satisfy the query \n\n q := datastore.NewQuery(\"Widget\").\n \tFilter(\"x =\", 1).\n \tFilter(\"x =\", 2)\n\neven though neither of the entity's individual `x` values satisfies both filter conditions.\n\nSimilarly, the sort order for multiple-valued properties is unusual. Because such properties appear once in the index for each unique value, the first value seen in the index determines an entity's sort order:\n\n- If the query results are sorted in ascending order, the smallest value of the property is used for ordering.\n- If the results are sorted in descending order, the greatest value is used for ordering.\n- Other values do not affect the sort order, nor does the number of values.\n\nThis has the unusual consequence that an entity with property values `1` and `9` precedes one with values `4`, `5`, `6`, and `7` in both ascending *and* descending order.\n\nQueries inside transactions must include ancestor filters\n---------------------------------------------------------\n\nDatastore [transactions](/appengine/docs/legacy/standard/go111/datastore/transactions) operate only on entities belonging to the same [entity group](/appengine/docs/legacy/standard/go111/datastore/entities) (descended from a common ancestor). To preserve this restriction, all queries performed within a transaction must include an [ancestor filter](#ancestor_filters) specifying an ancestor in the same entity group as the other operations in the transaction."]]