A production endpoint using EF Core became slow after data grew. How would you investigate it?

In production I preserve a before snapshot: latency percentiles, execution count, rows returned, command count, logical reads, CPU, waits, timeouts, and the plan for representative fast and slow parameter shapes. Test data must resemble production cardinality and skew, since tiny databases produce different plans. The repair follows the cause: project fewer columns, bound the result, use stable keyset pagination, remove an N+1 path, reshape a join, split only when cartesian expansion is the problem, add or adjust an index with write cost understood, update statistics, or build a dedicated read model. Raw SQL is a considered last step when the needed shape cannot be expressed or translated well, not the first escape hatch. I test semantic equivalence, authorization filters, cancellation, and query count, then roll out with a feature flag or canary if blast radius is meaningful. Database migrations remain backward compatible and index creation is planned for lock, log, and resource impact. After release I compare the same evidence, watch for regressions in other query shapes and writes, and retain a lightweight performance guard around this hot path. That proves the bottleneck moved without merely making one local benchmark look faster.