Schema & Indexes
The Schema & Indexes domain tests whether you can choose the right index or constraint for a query shape, read schema state, and recognize when the planner will or will not use an index.
Index types
Range indexes are the default and serve equality, range, and sorting on one or more properties. Text indexes serve string predicates such as STARTS WITH and CONTAINS. Point indexes serve spatial queries. Token lookup indexes serve label and relationship-type lookups. Full-text indexes are queried through procedures - CALL db.index.fulltext.queryNodes('idx', $q) YIELD node, score - rather than by the planner from a MATCH pattern, and their updates are applied asynchronously, so a just-committed node may not be searchable for a moment.
Constraints
Uniqueness (REQUIRE n.email IS UNIQUE), existence (REQUIRE n.email IS NOT NULL), and node key (Enterprise: uniqueness plus existence across a property combination). Creating a constraint creates a backing index; the command fails if existing data violates the rule. SHOW INDEXES and SHOW CONSTRAINTS report names, types, and state - an index in POPULATING state is not yet usable.
Worked example
Query: MATCH (p:Person) WHERE p.lastName = $ln AND p.firstName = $fn RETURN p. Index: CREATE INDEX person_name IF NOT EXISTS FOR (p:Person) ON (p.lastName, p.firstName). Reasoning: composite index order matters - the leading property must be constrained for the planner to seek. Queries filtering on firstName alone cannot use this index.
Traps
Expecting an index seek when the MATCH omits the label, because the planner needs a label to pick a schema index. Adding a plain index next to a unique constraint that already backs one. Trying to query a full-text index with a MATCH pattern. Forgetting that schema changes should precede bulk loading so MERGE lookups are indexed.