sql-query-optimization

Diagnose and optimize slow SQL queries using execution plans, index strategy, and predicate rewrites.

1|Updated Jul 3, 2026
One-click install
npx skills add https://github.com/Nandansai08/skillz --skill sql-query-optimization-nandansai08
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sql-query-optimization
Source: https://github.com/Nandansai08/skillz/tree/main/skills/data-analytics/sql-query-optimization
Command: npx skills add https://github.com/Nandansai08/skillz --skill sql-query-optimization-nandansai08

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Slow SQL queries waste engineering time and degrade application performance, and guessing at fixes (adding random indexes, trusting dev-database timings) rarely works. This Skill provides a disciplined workflow that reads actual execution plans to find where time really goes before changing anything. ## Core Features & Use Cases - Execution plan analysis: Run EXPLAIN (ANALYZE, BUFFERS) at production scale and read the three classic signals — row estimate drift, the node where actual time concentrates, and sequential scans under selective filters. - Index strategy: Design composite indexes in the correct column order, use covering and partial indexes, and verify the planner actually adopts them with a re-EXPLAIN. - Antipattern rewrites: Fix non-sargable predicates (function-wrapped columns, type mismatches, leading-wildcard LIKE), N+1 ORM patterns, OFFSET pagination, and DISTINCT band-aids hiding fan-out joins. - Use Case: A dashboard query timing out at 30 seconds gets diagnosed via EXPLAIN ANALYZE revealing stale statistics and a DATE() wrapper blocking an existing index; after an ANALYZE and a range-predicate rewrite it runs in 90ms with no new index. ## Quick Start Ask the agent to analyze why your slow Postgres query is timing out by running EXPLAIN ANALYZE and recommending index or rewrite fixes.

Frequently Asked Questions about sql-query-optimization

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I optimize a slow SQL query in Postgres?▼

Start by running EXPLAIN (ANALYZE, BUFFERS) against production-scale data to find where actual time concentrates. Check for stale statistics, non-sargable predicates, and missing indexes before rewriting the query or adding indexes.

How to read EXPLAIN ANALYZE output in PostgreSQL?▼

Look for three signals: actual rows versus estimated rows off by 100x or more indicating stale statistics, the node where actual time concentrates, and sequential scans on large tables under selective WHERE clauses. Optimize the slowest node, not the query you assume is slow.

Why is my index not being used by the query planner?▼

Common causes include functions wrapping the column like DATE(created_at), type mismatches causing silent casts, leading-wildcard LIKE patterns, and stale statistics. Rewrite predicates as ranges and run ANALYZE, then re-EXPLAIN to verify adoption.

Does this approach work for Spark or data warehouse queries?▼

No, this workflow is OLTP-shaped for Postgres and MySQL. Distributed engine problems like skew and shuffle in Spark or warehouses require different diagnosis techniques covered by a separate spark-etl-debugging skill.

Why is my query fast in development but slow in production?▼

Small dev datasets make sequential scans legitimately faster than index lookups, so dev-scale plans predict nothing about production behavior. Always run EXPLAIN ANALYZE against production-representative data volumes before drawing conclusions.

How do I fix N+1 query problems from an ORM?▼

Log the actual SQL the ORM generates to confirm per-row query patterns, then replace them with a join or IN clause rather than adding indexes. One query per row in application logs is the telltale sign of an N+1 pattern.