In EF Core, fix order beats the fix list, and compiled queries rank eighth for a reason

Order the first three fixes by what multiplies their cost. Change tracking, in the guide's own description, spends memory and CPU on change detection for every entity a read path materializes ^[7]. Loading whole rows when two or three columns would do inflates payload and materialization cost ^[8]. Both of those are charges per row. Pagination is the only one of the three that decides how many rows there are to charge for ^[9]. A checklist ordering and an arithmetic ordering are therefore different documents: a page cap shrinks the multiplier, AsNoTracking and projection shrink the per-row coefficient, and shrinking the coefficient on an unbounded set only makes the accidental load test ^[9] cheaper by the unit. The guide's own rule, filter and sort and paginate before materialization ^[10], says the same thing in the language of query composition rather than cost.

Compiled queries sit eighth of ten in both orderings the article publishes ^[14]. The supplied text breaks off mid-sentence inside the client-side evaluation section ^[17], so whatever it credits compiled queries with saving is not on the page I have; what is on the page, described as growing with data volume, is tracking work, materialization work and row count ^[7][8][9]. A saving that is fixed per invocation cannot outrun one that scales with rows, whatever its absolute size, and that is the whole case for the sequence.

Instrument before you touch code is the right instruction, and the guide gives the wiring: logging on the DbContext registration, with sensitive data logging fenced to development ^[5]. The triage table is thinner than it looks. Many SELECTs per request points at N+1, a huge row count for a small parent set at cartesian explosion, heavy tracking snapshots on a read endpoint at missing AsNoTracking, and a list endpoint with no LIMIT at missing pagination ^[6]. That is four of the ten items ^[16]. The remaining six are found by reading code and schema, not by watching a log stream, which is worth knowing before someone budgets an afternoon of log reading against all ten.

Nothing here is quantified. The excerpt carries no P95 before and after, no row counts, no materialization timings ^[17], so the ordering is a hypothesis about your workload rather than a measurement of it. The one testable idea the guide does supply is its definition: a data access pattern that returns correct results in development, passes tests, and degrades under real data volume or concurrency ^[4]. Read as a diagnostic, that points at the seed data rather than the query. If the dataset in your test environment had production cardinality, four of these ten mistakes would fail a test instead of a customer.