XenForo Fixing a Sudden Increase in the xf_search Table Size

[Thirtynader]

If you've noticed your forum's database size jump unexpectedly, and after checking phpMyAdmin found that the xf_search table is the culprit (sometimes hundreds of MB to a few GB!), this guide covers the cause and the fix.

Symptoms​

• Overall database size has grown significantly without a matching increase in actual content
• Checking table sizes in phpMyAdmin shows xf_search is abnormally large (even if the row count isn't huge size is the issue, not row count)

Important: xf_search is not the same as xf_search_index:

• xf_search_index → the main content search index (topics, posts, etc.)
• xf_search → the cache of search results run by users and guests

The bloat is almost always in this second table (the results cache), not the content index.

Why does this table grow?​

Every time someone runs a search, the result set gets stored as a row (with serialized result data) in this table to speed up pagination of search results. Common reasons it grows abnormally:

1. Very broad or high-match searches - a search term that matches nearly all content on the forum can produce a single row that's several MB to hundreds of MB in size.
2. High guest search traffic if guests are allowed to search, every visitor (including bots and scrapers) can generate new rows in this table.
3. Bot/scraper activity or an attack bots repeatedly hitting the search page with varying queries can bloat this table quickly.
4. The cleanup cron job isn't running properly XenForo has a scheduled task called "Rebuild expired search forum caches" that's supposed to periodically clean this table. If it's disabled, or the host's server-side cron isn't actually firing it, the table grows unchecked.

The fix​

Before you start​

• Always back up your database before making changes.
• The steps below are completely safe no posts, threads, or content are deleted, since xf_search is purely a temporary cache table.

Step 1 - What usually does NOT help​

Running "Rebuild Search Index" from:
ACP > Tools > Rebuild Search Index
or running OPTIMIZE TABLE xf_search; usually won't fix this, because these act on the xf_search_index table (content index), not the xf_search cache table where the actual bloat is.

Step 2 - The actual fix: truncate the cache table​

Via phpMyAdmin:

1. Select your forum's database
2. Go to the SQL tab
3. Run:

TRUNCATE TABLE xf_search;

After running this, the table size drops to a few KB immediately and your database returns to its real size. The only effect is that users will need to re-run their searches nothing else is lost.
If your hosting control panel still shows the old (larger) database size while phpMyAdmin already shows the correct one, don't worry this is usually just a disk usage cache on the hosting panel's side and typically updates within 24 hours.

Step 3 - Check the related cron entry​

To prevent this from happening again, go to:
ACP > Tools > Cron Entries
Look for "Rebuild expired search forum caches" and confirm:

• It's enabled
• Its "Next run" time actually advances after it passes (confirming the host's server-side cron is correctly calling XenForo's cron.php)

If it's disabled, or the next-run time never updates, contact your host and ask them to check whether server-side cron jobs are firing correctly.

Precautionary step (only if you suspect an attack or abnormal traffic)​

If after truncating the table it starts growing rapidly again especially if your server logs or traffic stats point to bot/scraper activity or a suspected attack you can, as a precaution, disable search for guest users.

Only do this if you genuinely suspect abnormal traffic or an attack, since disabling guest search affects user experience (and in some cases, SEO). If this was just normal accumulation (which the working cron job should now prevent), this step isn't necessary.