การทำดัชนีคำค้นเพื่อประสิทธิภาพ

Querying with orderByChild works on small data, but as nodes grow, unindexed queries force the client to download and sort everything. That is slow and expensive.

Indexes tell Firebase to pre-sort data on the server for a given field.

Run an orderByChild query on a field with no index and Firebase logs a warning: it had to perform the sort on the client. In large datasets this is a real performance problem.

Indexes are declared in your Security Rules using the .indexOn directive at the parent of the records you query.

The indexed field must match the field you order by. This query benefits from the age index above.

You can index several fields under the same node by listing them. Each supports a different orderByChild query.

For queries using orderByKey or orderByValue, use the special tokens .key and .value in the index list.

When records sit under a dynamic parent (like per-user lists), put .indexOn inside a wildcard segment so it applies to every child group.

Unlike some databases, Realtime Database indexes add no extra storage cost and are maintained automatically. The trade-off is simply that you must declare them in rules ahead of time.

Indexing speeds queries, but it does not replace good data modeling. If you constantly query by a field, consider also restructuring data so the common access pattern is a direct lookup.

Keep these constraints in mind:

• You can order by only one field per query
• The index field must exist on the child for it to appear in results
• Deeply nested data is harder to index efficiently

After deploying rules, re-run the query and confirm the unindexed warning is gone from the logs. That confirms the server is now doing the sort.

Your queries are now ready to scale.

• Unindexed orderByChild sorts on the client and warns
• Declare indexes with .indexOn in Security Rules
• Match the indexed field to your query field
• Use .key / .value for key and value ordering
• Index inside wildcards for dynamic parents