Queries that were instant at launch and crawl a year later: scale-aware investigation of work that grows faster than the data, before it owns the server.
Some queries do not have a bug — they have a trajectory. This prompt uses the scaling goal on the classic case: dashboard queries degrading every month as data grows. The priorities target growth itself: reason at the scale every conclusion assumes (fine at 100K rows can own the server at 100M), identify work that grows faster than the data — join shapes that multiply, sorts that will spill, aggregates over ever-growing history — bound the working set with time-windowing and keyset pagination, and check growth asymmetry, because the right plan today may invert as table ratios change. The symptom framing matters: degradation correlated with data growth is itself evidence about the cause's shape.
Read the trajectory as evidence
Month-over-month degradation points at growth-coupled work — the symptom narrows the suspects.
Find the super-linear work
What grows faster than the data: multiplying joins, spilling sorts, unbounded aggregates.
Bound the working set
Time windows, keyset pagination, pruning — queries that touch a bounded set stop degrading.
That's the wrong fit. This prompt targets the large-dataset-scaling goal — queries that degrade month over month as data grows, reading the trajectory itself as evidence. A sudden overnight regression points at a deployment, which the resource routes to the Debugging Prompt Generator. Use this one when slowness correlates with volume, not with a recent change.
Its QUERY CONTEXT rules say the plan is "not provided. Do not invent one," so plan-dependent conclusions are marked pending until you capture it with your engine's actual-execution-plan facility. Same for row counts and existing indexes. When essential evidence is missing, the first recommendations become the commands to gather it rather than guesses standing in for it.
It's the super-linear lens: the analysis hunts join shapes that multiply, sorts that will spill, and aggregates over ever-growing history — operations whose cost outpaces row growth. It also checks growth asymmetry (which tables grow, which stay constant) because the right plan today can invert as ratios change, and recommends bounding the set with keyset pagination instead of OFFSET.
A five-table join that got slow as data grew: establish cardinality first, check each join strategy against the data shape, and hunt the fan-out doing wasted work.
"Optimize this query" gets generic indexing advice. The optimization contract demands evidence: real bottlenecks, justified indexes with their write tax, and no invented plans.
Optimize what the engine does, not what the SQL looks like: cost concentration, estimate-vs-actual gaps, and plan warnings — with forensic evidence rules.
"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.
"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.
"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.
Build evidence-based SQL optimization prompts — goal, platform, and the evidence you have turn into a query tuning contract.