How to reduce database load on a busy site

A database that once responded instantly can slow down gradually as a site grows, and the cause is rarely one dramatic event — it is usually a combination of more data than there used to be, queries that were never quite efficient to begin with, and no caching in front of any of it to absorb repeated requests for the same thing. None of that needs a bigger server to fix; most of it is maintenance and caching that would help on any hosting.

Find the actual query before changing anything

Guessing at database problems wastes time that finding the real one does not. How to find the query slowing your site down covers identifying, with evidence, which specific query is responsible rather than optimising in the dark. This matters because the fix for "one query without an index" and the fix for "too much unindexed data overall" are different, and treating one as the other wastes effort.

Cache what does not need to be queried every time

The most effective way to reduce database load is often not making the database faster at all — it is asking it the same question fewer times. If ten thousand visitors load a page that runs the same query to fetch the same, unchanging content, running that query ten thousand times is ten thousand times more work than running it once and reusing the result.

• Page caching avoids the query entirely for cached requests, because the whole page is served without regenerating it — see how page caching works.
• Object caching caches the result of a specific expensive query so it can be reused across different pages that all need the same data, even where the pages themselves cannot be cached as a whole — covered in caching a site that changes constantly.

Between the two, most of the repeated, avoidable load on a typical database is eliminated before it ever needs to be optimised at the query level at all.

Clean up what has quietly built up

Most content management systems accumulate data over time that nobody explicitly asked for and nobody is using: old revisions of edited content, expired session and transient data, spam comments that were never fully purged, logs from plugins that have long since been removed. None of this is doing anything useful, and all of it adds to the amount of data every relevant query has to work through.

Check indexes on what you actually search or filter by

A database index lets the database jump directly to relevant rows instead of examining every row in a table to find matches — the same idea as an index at the back of a book saving you from reading every page to find a topic. A query filtering or sorting by a column that has no index gets proportionally slower as the table grows, because there is more to check through each time. This is a common, specific cause of a site that used to be fast and has slowed down gradually as its content or order volume grew, rather than after any single change.

Watch for too many simultaneous connections

Every request that needs the database opens a connection to it, and there is a limit to how many can be open at once. A sudden burst of traffic, or a plugin or script that opens connections and does not close them properly, can exhaust that limit and produce a visible, site-wide error rather than a gradual slowdown. How to fix a "too many connections" error covers this specific failure mode and how to prevent it recurring.

A practical order to work through

1. Identify the actual slow query with evidence

   Rather than guessing which part of the site is responsible.

2. Add or confirm caching for repeated, unchanging queries

   This removes the largest share of avoidable load on most sites before anything else is touched.

3. Clean up accumulated unused data

   Old revisions, expired sessions, spam, orphaned data from removed plugins.

4. Check indexes on frequently filtered or sorted columns

   Particularly on tables that have grown substantially since the site launched.

5. Put cleanup on a recurring schedule

   So the same categories of clutter do not simply build back up over the following months.

A database that has been genuinely optimised this way, with caching correctly absorbing repeat requests, needs considerably more sustained traffic before hosting resources become the limiting factor — which is the honest way to think about when an upgrade is actually warranted, covered in how to tell when you have outgrown your plan.