Skip to content
DevOps AI ToolKit
Newsletter
All prompts
AI for MySQL Difficulty: Intermediate ClaudeChatGPTCursor

MySQL Unused & Redundant Index Audit Prompt

Find indexes that are never used or are duplicated/prefix-redundant, and decide which are safe to drop to cut write and storage overhead.

Target user
DBAs and backend engineers reducing index bloat on write-heavy tables
Difficulty
Intermediate
Tools
Claude, ChatGPT, Cursor

The prompt

You are a senior MySQL/MariaDB DBA who prunes index bloat safely. You know that every secondary index adds write amplification, buffer-pool pressure, and disk usage, and that redundant indexes (exact duplicates or left-prefix subsets) are pure overhead. You also know that "unused" from performance_schema is only true for the observation window, and that invisible indexes (MySQL 8.0) are the safe way to test a drop.

I will provide:
- Output of a usage query from sys.schema_unused_indexes and/or performance_schema.table_io_waits_summary_by_index_usage: [PASTE]
- Uptime / how long performance_schema has been collecting since the last reset: [STATE]
- `SHOW CREATE TABLE` for the candidate tables, listing all indexes: [PASTE]
- Table sizes and rough read/write ratio: [DESCRIBE]
- Any known periodic jobs (reports, batch, failover queries) that may use rare indexes: [DESCRIBE]

Work through this:

1. **Separate two categories.** (a) Redundant/duplicate indexes — exact duplicates and left-prefix subsets (an index on (a) when (a,b) exists) — which can be judged from the schema alone. (b) Genuinely unused indexes — which depend on the observation window and must be treated cautiously.
2. **For redundant indexes**, name the covering index that makes each one redundant and confirm the drop cannot lose a useful access path (watch for UNIQUE constraints and different column orders that are NOT prefix-redundant).
3. **For unused indexes**, assess whether the observation window is long enough (question anything based on hours or days of uptime), and flag any index whose columns match a known periodic job.
4. **Rank drop candidates** by benefit (write/storage saved on hot tables) and risk (uniqueness constraints, short window, rare-query suspicion).
5. **Prescribe a safe procedure**: set the index INVISIBLE first (8.0), observe for a full business cycle, then DROP; keep the exact CREATE INDEX statement recorded for instant rollback.

Output: (a) Redundant/duplicate list with the index that supersedes each, (b) Unused candidates with a confidence level and the window caveat, (c) Ranked drop plan, (d) Invisible-index staging + rollback statements, (e) Risks and what to monitor after.

Guardrails: never drop a UNIQUE index without confirming the constraint is not relied on for data integrity; require an observation window covering at least one full business cycle before trusting "unused"; stage every drop as an invisible index and record the CREATE statement so any regression is instantly reversible.

Run this prompt with AI

Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.

Why this prompt works

Index audits go wrong in two opposite ways: engineers keep every index forever out of fear, or they drop one that quietly served a monthly report and cause a Monday-morning fire. This prompt splits the problem into the part that can be judged safely from the schema alone — exact duplicates and left-prefix subsets — and the part that depends on observation, which it treats with appropriate suspicion. That separation is what makes the recommendations trustworthy rather than reckless.

By demanding the performance_schema uptime and forcing the model to question any “unused” verdict based on a short window, the prompt encodes the single most common mistake in index pruning. It also catches the subtle traps — a UNIQUE index that enforces a business rule, or a different column order that only looks redundant — that a naive duplicate-finder would delete.

The staged rollout through invisible indexes is the operational heart of the prompt. Making an index invisible lets the optimizer ignore it while keeping it instantly restorable, so a plan regression is a one-line fix rather than an hours-long rebuild on a large table. Recording the exact CREATE INDEX statement means every drop is reversible, keeping the engineer in control of the change.

Related prompts

More MySQL prompts & error guides

Browse every MySQL prompt and troubleshooting guide in one place.

Free download · 368-page PDF

Reading prompts? Get all 500 in one free PDF

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.