Bring the generated SQL, representative parameters, execution plan, and row counts to the review. Syntax alone cannot explain the cost.
Describe the job of the query
Start with the screen or operation the query serves. State which fields it needs, its maximum result size, its sort order, and how fresh the data must be. Those requirements define what the database actually has to do.
Before asking an assistant to optimize anything, capture a baseline. Use representative data and parameters. Keep a slow example and an ordinary example; an optimization that only helps one case may make the common path worse.
Review three concrete costs
For read-only results, evaluate the tracking behavior as well. Do not apply a rule automatically: verify how the query materializes data and whether the application needs entity tracking.
- Rows examined: inspect whether filters and ordering can use suitable indexes.
- Rows and columns returned: project the fields the operation needs and bound the result set.
- Round trips: identify repeated queries and related data loading that grows with the number of records.
Give the assistant enough evidence
Review this EF Core query with its generated SQL and plan. The operation needs only the fields listed below. Identify avoidable rows, columns, and round trips. Separate recommendations supported by the plan from ideas that still require measurement. Preserve ordering, tenant filters, and pagination semantics. Explain the write and storage cost of any proposed index.
Measure the change you intend to ship
Compare database duration, logical reads where available, result size, and application latency. Test the first and later pages of a paginated query and include realistic concurrency. Keep the result contract stable so that a faster query does not become a subtle correctness bug.
Save the query and its measurements beside the change. That gives the next reviewer something stronger than a claim that the generated LINQ looks cleaner.