菜单
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".
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/jeremylongshore/claude-code-plugins-plus-skills --skill analyzing-query-performance命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
Implement user sign-up and sign-in flows with Clerk. Use when building authentication UI, customizing sign-in experience, or implementing OAuth social login. Trigger with phrases like "clerk sign-in", "clerk sign-up", "clerk login flow", "clerk OAuth", "clerk social login".
Implement session management and middleware with Clerk. Use when managing user sessions, configuring route protection, or implementing token refresh and custom JWT templates. Trigger with phrases like "clerk session", "clerk middleware", "clerk route protection", "clerk token", "clerk JWT".
Configure enterprise SSO, role-based access control, and organization management. Use when implementing SSO integration, configuring role-based permissions, or setting up organization-level controls. Trigger with phrases like "clerk SSO", "clerk RBAC", "clerk enterprise", "clerk roles", "clerk permissions", "clerk organizations".
| 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 <jeremy@intentsolutions.io> |
| license | MIT |
| tags | ["database","performance","analyzing-query"] |
| compatibility | Designed for Claude Code, also compatible with Codex and OpenClaw |
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.
EXPLAIN ANALYZE (PostgreSQL), EXPLAIN FORMAT=JSON (MySQL), or explain() (MongoDB)pg_stat_statements extension enabled for PostgreSQL (provides aggregated query statistics)psql, mysql, or mongosh CLI tools installedIdentify 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.
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.
Analyze the execution plan for these red flags:
rows_removed_by_filter relative to rows (predicate not selective enough)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.
Evaluate index usage with SELECT indexrelname, idx_scan, idx_tup_read, idx_tup_fetch FROM pg_stat_user_indexes WHERE schemaname = 'public' ORDER BY idx_scan ASC. Indexes with zero scans are unused and waste write performance.
Check for table bloat using SELECT relname, n_live_tup, n_dead_tup, n_dead_tup::float / GREATEST(n_live_tup, 1) AS dead_ratio FROM pg_stat_user_tables WHERE n_dead_tup > 1000 ORDER BY dead_ratio DESC. A dead tuple ratio above 0.2 indicates the table needs VACUUM.
For each identified issue, generate a specific recommendation: CREATE INDEX statement with the exact columns, query rewrite suggestions, or configuration parameter adjustments.
Estimate the performance impact of each recommendation by comparing the EXPLAIN plan before and after applying the change on a staging database or by analyzing the expected row reduction from new indexes.
Prioritize recommendations by impact-to-effort ratio: index additions (high impact, low effort) before query rewrites (medium impact, medium effort) before schema changes (high impact, high effort).
Generate a performance analysis report with before/after execution plans, estimated improvements, and implementation priority ranking.
| Error | Cause | Solution |
|---|---|---|
EXPLAIN ANALYZE takes too long on production | Query modifies data or runs for minutes | Use EXPLAIN without ANALYZE for estimated plans; run EXPLAIN ANALYZE on staging with representative data |
pg_stat_statements not available | Extension not installed or not in shared_preload_libraries | Run CREATE EXTENSION pg_stat_statements; add to shared_preload_libraries in postgresql.conf and restart |
| Execution plan differs between staging and production | Different data distribution, statistics, or configuration | Run ANALYZE on staging tables to update statistics; match work_mem, random_page_cost, and effective_cache_size settings |
| Index recommendation causes slow writes | Too many indexes on a write-heavy table | Limit indexes to 5-7 per table; use partial indexes to reduce scope; consider covering indexes to replace multiple single-column indexes |
| Query plan uses wrong index | Stale statistics or cost model miscalculation | Run ANALYZE table_name to refresh statistics; adjust random_page_cost for SSD storage; use SET enable_seqscan = off to test index plans |
Optimizing a dashboard aggregate query: A query computing daily revenue with GROUP BY date and JOIN across orders and line_items takes 12 seconds. EXPLAIN reveals a sequential scan on line_items (5M rows). Adding a composite index on (order_id, created_at) with INCLUDE (amount) reduces execution to 200ms by enabling an index-only scan.
Diagnosing N+1 query pattern: Application loads a list page showing 50 products, each with a separate query for category name. pg_stat_statements reveals SELECT name FROM categories WHERE id = $1 called 50 times per page load. Resolution: rewrite as a single JOIN query or implement eager loading in the ORM.
Identifying bloated table causing cache misses: Buffer cache hit ratio drops to 0.78 on the sessions table. Investigation reveals 80% dead tuples due to aggressive INSERT/DELETE cycling without autovacuum tuning. Setting autovacuum_vacuum_scale_factor = 0.01 and running VACUUM FULL restores cache hit ratio to 0.99.