analyzing-query-performance

name	analyzing-query-performance
description	Execute use when you need to work with query optimization. This skill provides query performance analysis with comprehensive guidance and automation. Trigger with phrases like "optimize queries", "analyze performance", or "improve query speed".
allowed-tools	Read, Write, Edit, Grep, Glob, Bash(psql:*), Bash(mysql:*), Bash(mongosh:*)
version	1.27.0
author	Jeremy Longshore <[e-mail]>
license	MIT
tags	["database","performance","analyzing-query"]
compatibility	Designed for Claude Code

Query Performance Analyzer

Overview

Analyze slow database queries using execution plans, wait statistics, and I/O metrics across PostgreSQL, MySQL, and MongoDB. This skill captures EXPLAIN output, identifies sequential scans on large tables, detects missing indexes, measures buffer cache hit ratios, and produces actionable optimization recommendations ranked by expected performance impact.

Prerequisites

• Database credentials with permissions to run EXPLAIN ANALYZE (PostgreSQL), EXPLAIN FORMAT=JSON (MySQL), or explain() (MongoDB)
• pg_stat_statements extension enabled for PostgreSQL (provides aggregated query statistics)
• Access to slow query logs or performance_schema (MySQL)
• Baseline query execution times for comparison
• psql, mysql, or mongosh CLI tools installed

Instructions

1. Identify the slowest queries by examining pg_stat_statements (PostgreSQL): SELECT query, calls, mean_exec_time, total_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 20. For MySQL, enable and query the slow query log or performance_schema.events_statements_summary_by_digest.

2. Run EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) on each slow query in PostgreSQL, or EXPLAIN ANALYZE FORMAT=JSON in MySQL. Capture the full execution plan including actual row counts, loop iterations, and buffer usage.

3. Analyze the execution plan for these red flags:

   • Sequential scans on tables with >10,000 rows (indicates missing index)
   • Nested loop joins with high outer row counts (consider hash join or merge join)
   • Sort operations without index support (adding a covering index eliminates the sort)
   • High rows_removed_by_filter relative to rows (predicate not selective enough)
   • Bitmap heap scans with high recheck rate (index selectivity too low)

4. Check buffer cache performance: SELECT heap_blks_read, heap_blks_hit, heap_blks_hit::float / (heap_blks_hit + heap_blks_read) AS cache_hit_ratio FROM pg_statio_user_tables WHERE relname = 'table_name'. A ratio below 0.95 suggests the working set exceeds available shared_buffers.