PunBB keeps its entire state in a compact MySQL or MariaDB schema, which is one reason it stays fast on modest shared hosting. That same compactness means a handful of tables carry almost all the load, and when one of them bloats, develops a crashed index, or loses its connection credentials, the symptoms spread across the whole board. On a managed shared plan you cannot touch my.cnf, restart the database service, or run SET GLOBAL statements, so every repair here happens inside phpMyAdmin, File Manager, and the PunBB admin panel. The good news is that PunBB's schema is small and predictable enough that you can diagnose and correct most issues yourself from these tools.

Understanding the PunBB schema and where bloat accumulates

A standard PunBB 1.4 installation ships roughly two dozen tables, all sharing the prefix you chose during setup (the default is no prefix, but many installs use something like pun_). You can confirm the exact prefix by opening cPanel → File Manager (or DirectAdmin → File Manager), navigating to your PunBB root, and reading config.php. The line $db_prefix tells phpMyAdmin which tables belong to this forum, which matters if the same database hosts several applications.

The tables that grow and cause trouble are predictable. posts holds every message body and is almost always the largest table by data size. topics tracks threads and their reply counters. search_cache and search_matches back the full-text search feature and are the single biggest source of silent bloat, because PunBB caches search result sets and the matches index expands with every post. online records who is viewing the board right now and is supposed to be ephemeral, but a misconfigured cron or a crash can leave stale rows behind. Finally config is tiny but critical, since a corrupted row there can take the whole board offline.

To see the real picture, open phpMyAdmin from your control panel, select the PunBB database in the left sidebar, and click the Structure tab. The table list shows row counts and the size of each table. Sort by size and you will usually find search_matches and search_cache consuming a disproportionate amount of space relative to the actual post count. A forum with 20,000 posts can easily carry 200,000 rows in search_matches. That is normal to a point, but when the search tables dwarf posts by a large multiple, or when your account is bumping the disk quota shown in cPanel's Statistics sidebar, it is time to trim.

Clearing the search cache is safe and reversible, because PunBB rebuilds entries on demand. Run the following in the phpMyAdmin SQL tab, adjusting the prefix to match your install:

TRUNCATE TABLE pun_search_cache;

The search_cache table can always be truncated with no data loss. The search_matches table is different: it is the actual word index, and truncating it breaks search until you rebuild it. If you must reclaim that space, rebuild the index afterward from Admin → Maintenance → Rebuild index inside the PunBB admin panel, which repopulates search_words and search_matches in batches sized for shared-hosting limits.

Diagnosing broken tables and connection errors

When PunBB throws Unable to connect to MySQL server or Table './db/pun_posts' is marked as crashed, the message is almost always literal. A connection failure means the credentials in config.php no longer match the database. On shared hosting this happens after a password reset in cPanel → MySQL Databases or DirectAdmin → MySQL Management that was not mirrored into the config file. Open config.php in File Manager and check these four lines against what the control panel shows:

$db_host = 'localhost';
$db_name = 'cpaneluser_punbb';
$db_username = 'cpaneluser_punuser';
$db_password = 'the-exact-current-password';

On cPanel and DirectAdmin the database and user names are prefixed with your account name, and localhost is correct for almost every managed shared plan. If you reset the password, re-enter it here exactly, with no trailing spaces, and confirm the user is still attached to the database with ALL PRIVILEGES in the control panel's database user screen. A user that was accidentally detached produces the same connection error even when the password is right.

A crashed table is a different problem. MyISAM tables, which older PunBB installs use by default, can be left in an inconsistent state after an abrupt process termination, often triggered when a long query hits the CloudLinux LVE limits on your account and is killed mid-write. You repair these without any shell access. In phpMyAdmin, go to the Structure tab, tick the checkbox beside the affected table (or use Check all), and from the With selected dropdown choose Repair table. phpMyAdmin issues the equivalent of REPAIR TABLE, which you are permitted to run as a normal database user. Follow that with Check table to confirm the status reads OK. If a table reports as InnoDB rather than MyISAM, the repair option will note that InnoDB handles its own crash recovery; in that case the fix is usually a connection or privilege issue rather than physical corruption.

Run these checks against posts, topics, search_matches, and online first, since those see the most write traffic and are the usual victims of a mid-write kill.

Finding slow queries and verifying indexes

Slow page loads on a PunBB board that was previously quick almost always trace back to either missing indexes after a botched import or an overgrown table scanned without an index. You cannot enable the server-wide slow query log, but you can reproduce the diagnosis per query inside phpMyAdmin. Take a query that mirrors what PunBB runs on a busy page, such as listing recent topics in a forum, and prefix it with EXPLAIN in the SQL tab:

EXPLAIN SELECT * FROM pun_topics
WHERE forum_id = 2
ORDER BY last_post DESC
LIMIT 30;

In the result, read the type and key columns. If key is NULL and type reads ALL, the query is doing a full table scan because the expected index is missing. A healthy PunBB schema carries indexes such as forum_id on topics, topic_id on posts, and user_id on posts. Verify them by opening the table's Structure tab and scrolling to the Indexes panel. If an index that the stock schema defines is absent, usually the aftermath of a selective import, recreate it from the same panel by choosing the column, setting a sensible index name, and saving. For example, restoring the posts-to-topic link:

ALTER TABLE pun_posts ADD INDEX topic_id (topic_id);

Never add random indexes hoping to speed things up; on shared hosting every extra index costs write time and disk, and PunBB's own schema is already tuned for its query patterns. Restore what the default schema defines and stop there. If PHP memory or execution time becomes the bottleneck during a large rebuild or import, raise the limits for your account through cPanel → MultiPHP INI Editor or a .user.ini file in the PunBB root with lines such as max_execution_time = 120 and memory_limit = 256M, then run the operation in smaller batches. The approach of reading a config file, matching credentials, and raising per-account PHP limits mirrors the method covered in our Phorum configuration and PHP limits guide.

Routine maintenance to keep the board healthy

PunBB includes a maintenance panel that handles most housekeeping without raw SQL. Under Admin → Maintenance you will find the Rebuild index tool, which safely regenerates search data in configurable per-pass chunks so it respects execution limits. Use it after any bulk prune, after restoring from a backup, or whenever search returns incomplete results. Set the posts-per-cycle value low (a few hundred) on constrained plans so each pass finishes well within your execution-time ceiling.

Pruning old content directly shrinks the two largest tables. The Admin → Prune screen deletes posts older than a chosen number of days in a selected forum, and because it removes rows from posts and updates topics counters in one operation, it is far safer than manual deletes in phpMyAdmin. After a large prune, the space is marked free but not returned to the operating system until the table is optimized. Reclaim it by selecting the pruned tables in phpMyAdmin's Structure tab and choosing Optimize table from the With selected dropdown, or run it directly:

OPTIMIZE TABLE pun_posts, pun_topics, pun_search_matches;

For MyISAM tables this rebuilds the file and defragments the indexes, which usually restores query speed on a table that has seen heavy deletion. Keep stale online rows in check by confirming the board's auto-cleanup is working; if you see thousands of rows there, the records are not expiring, and you can safely clear visitor entries with DELETE FROM pun_online WHERE user_id = 1; (guest rows), which PunBB repopulates immediately.

Before any of these operations, export a backup. Use phpMyAdmin → Export with the Custom method, gzip compression, and the full structure-and-data option, or trigger a full account backup from cPanel's Backup tool. A three-minute export is cheap insurance against a mistyped DELETE, and it gives you a clean restore point if a repair or optimize does not go as planned. Run the search index rebuild and a table optimize on a monthly schedule for an active board, verify table status reads OK after each, and your PunBB database will stay well within the resource limits of a shared plan.