What this prompt does
This prompt asks the AI to analyze and optimize specific Laravel Eloquent queries with before/after proof, not give generic advice. You paste [current_query] for your [model_name] model along with the table's [row_count] and its [related_tables], and the AI works through six fixes: N+1 problems via eager loading, missing indexes, over-selected columns, caching opportunities with [cache_driver], subquery-vs-join choices, and a pagination strategy — showing a query-count comparison via Laravel Debugbar and suggesting index migrations.
The structure works because it grounds the optimization in your real query and table shape. The [current_query] and [related_tables] variables tell the AI exactly where eager loading and joins matter, [row_count] signals when indexing and pagination become critical, and [cache_driver] (defaulting to Redis) targets the caching advice. Forcing a before/after query-count comparison makes the improvement provable rather than assumed.
When to use it
- You have a slow Laravel page and suspect N+1 queries or missing indexes.
- You want a specific query optimized with measurable before/after query counts.
- You're querying a large table (
[row_count]in the hundreds of thousands) and need a pagination strategy. - You want to know which columns and joins to cache with
[cache_driver]and which not to. - You need an index migration suggested for the joins on
[related_tables].
Example output
Expect a targeted optimization report: the rewritten [model_name] query with eager loading, a list of recommended indexes with a ready-to-run migration, columns to trim from the select, a caching approach using [cache_driver], a subquery-vs-join recommendation, and a pagination strategy suited to [row_count]. A before/after query-count comparison (framed around Laravel Debugbar) shows the N+1 collapse — analysis and code you can apply, not a vague checklist.
Pro tips
- Paste the real
[current_query]and any surrounding loop — the AI can't catch an N+1 it can't see. - List
[related_tables]accurately so eager-loading and index suggestions cover the actual joins, not guesses. - Give a realistic
[row_count]; it's what decides whether the AI recommends offset or cursor pagination. - Verify every suggested index against your real schema before migrating — a redundant index slows writes for no read gain.
- Treat the before/after counts as a hypothesis to confirm with Debugbar on your machine, since the AI estimates without running your app.
- Apply fixes one at a time (eager loading, then indexes, then caching) so you can attribute each query-count drop to a change.
