How to add missing database indexes in WordPress

An index lets MySQL find rows without scanning the whole table. WordPress ships with sensible core indexes, but plugins add tables and query patterns that core never anticipated, and large meta tables get queried on columns with no index at all. Adding the right index can turn a 2-second query into a 20-millisecond one.

What causes this?

Plugin tables created without indexes on the columns they filter by, meta queries on large wp\_postmeta tables, and lookups on option\_name patterns. The site works fine small, then slows as tables grow, because a full scan of 40,000 rows is invisible and a full scan of 4 million is not.

How to check

Enable slow query logging or use Query Monitor to capture the slowest repeated queries. For each, run EXPLAIN: "type: ALL" with a large row estimate means a full table scan. The audit does this analysis and names the exact query and column ("Index columns behind slow, repeated queries").

How to fix it manually

Adding an index locks writes on large tables while it builds. Do it in a low-traffic window, with a backup.

1. Back up the database

1. Confirm the offending query and column with EXPLAIN

1. Add the index

ALTER TABLE wp\_postmeta ADD INDEX meta\_key\_value (meta\_key(191), meta\_value(20)); Adjusted to the real column and prefix lengths for your case.

1. Re-run EXPLAIN

Confirm the type changed from ALL to ref or range.

1. Watch for the query in the slow log again

Over the next days.

How BoltAudit does it

The audit runs all of the above for you and turns it into one reviewed action.

1Finds it automatically: repeated slow queries with their scan counts as evidence.

2Preview the exact change. Which index, which table, estimated build impact.

3Automatic backup, then apply in a maintenance-aware click.

4Roll back any time; dropping an index is instant and safe.

Fix this on your site

Common questions

Can an index make things worse?

Rarely: indexes cost a little on writes and disk. One targeted index for a proven slow query is nearly always a clear win.

Why prefix lengths like meta\_key(191)?

MySQL limits index width; prefixes keep large text columns indexable.

Is this safe on shared hosting?

Yes, but do it off-peak; the build can pause writes on big tables.

Should I index everything queried?

No. Index the proven slow, repeated queries. More indexes are not better.