A mooSocial community accumulates database weight faster than most scripts because almost every action a member takes writes a row. Posting a status, liking a photo, following a friend, sending a notification, or loading a page that logs activity all push records into tables that rarely get pruned on their own. On shared hosting the symptoms arrive gradually: the newsfeed stalls, the admin dashboard takes several seconds to render, and occasionally you see a Error establishing a database connection message during traffic spikes. Because you are operating as an unprivileged hosting user, the fix never involves touching my.cnf, running SET GLOBAL, or restarting MySQL. Everything described here is done through phpMyAdmin, the cPanel or DirectAdmin interface, the mooSocial AdminCP, and the files inside your account.
Before changing anything, understand what mooSocial stores and where. The engine ships a schema prefixed by default with moo_ (your installer may have set something else, visible in config/database.php inside your document root). The heaviest tables in a mature site are predictably moo_feed, moo_feed_comment, moo_feed_like, moo_notification, moo_activity_log, and the session and cache helper tables. Knowing this lets you target maintenance precisely rather than guessing.
Measuring Bloat and Spotting the Heaviest Tables
Start by measuring, not assuming. Open phpMyAdmin from cPanel (Databases > phpMyAdmin) or DirectAdmin (Account Manager > MySQL Management, then the phpMyAdmin link), and select your mooSocial database in the left tree. Click the Structure tab for the whole database. phpMyAdmin lists every table with a Rows estimate and a Size column. Sort by size and you will usually find notification and feed-related tables dominating. For a precise, sortable view, use the SQL tab and run a query that reads from the information schema, which any unprivileged user can query for their own tables:
SELECT table_name,
table_rows,
ROUND(data_length/1024/1024, 2) AS data_mb,
ROUND(index_length/1024/1024, 2) AS index_mb,
ROUND(data_free/1024/1024, 2) AS free_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 25;The free_mb column is the one that reveals fragmentation. When data_free is large relative to the table size, the table has been written to and deleted from repeatedly, leaving gaps that inflate disk usage and slow sequential scans. A moo_notification table showing 400 MB of data and 120 MB of free space is a clear optimization candidate. Record these numbers so you can compare after cleanup and confirm the work had measurable effect.
Also check your total database size against the quota shown in cPanel under Databases > MySQL Databases or the DirectAdmin database listing. Shared plans often cap individual database size, and a bloated mooSocial install that brushes against that cap can start throwing write errors that look like connection failures but are really disk or quota rejections. If you see errors only during high activity, read the next section on connections before assuming the schema is the problem.
Pruning Unnecessary Data Safely
Much of mooSocial's bloat is disposable history. Old notifications, expired sessions, and stale activity entries have no functional value once they age out. Trim them through phpMyAdmin, but take a backup first. Use the Export tab, select Custom, choose the tables you intend to modify, and download a gzipped SQL dump to your workstation. On a large database the browser export may time out; in that case use cPanel's Backup wizard to generate a partial database backup that runs server-side and lands in your home directory for download through File Manager.
Notifications are the safest and most productive target. mooSocial rarely needs anything older than a few weeks, and members never miss pruned alerts. Run a scoped delete in the SQL tab, keeping the window conservative:
DELETE FROM moo_notification
WHERE created_at < (UNIX_TIMESTAMP() - 2592000)
LIMIT 50000;The LIMIT clause matters on shared hosting. Deleting millions of rows in one statement can exceed the max_execution_time enforced on your PHP and MySQL layer and leave a half-finished operation. Run the statement repeatedly until phpMyAdmin reports zero rows affected. Note that mooSocial stores timestamps as UNIX integers in most activity tables; if a particular table uses a DATETIME column instead, switch the comparison to WHERE created_at < NOW() - INTERVAL 30 DAY. Always confirm the column type on the Structure tab before running a delete so you do not accidentally match everything.
Session and cache tables are equally safe to clear. If your install uses database sessions, truncating expired rows frees space immediately without affecting logged-in users whose sessions are current. Spam and orphaned records deserve attention too: deleted members sometimes leave dangling rows in moo_feed and moo_feed_comment. The mooSocial AdminCP under Spam > Manage and the member management screens handle most of this through the application, which keeps foreign relationships intact. Prefer the AdminCP for anything tied to users, and reserve raw SQL for clearly disposable log and notification data.
Repairing Broken Tables and Reclaiming Space
A hard process kill, a disk-full event, or an interrupted import can leave a MyISAM table marked as crashed, which mooSocial surfaces as blank feed sections or an outright database error. phpMyAdmin exposes the repair tools without any shell access. On the database Structure page, tick the affected tables, then use the With selected dropdown at the bottom and choose Repair table. For InnoDB tables, which make up most of a modern mooSocial schema, true repair happens at the engine level and is outside your reach, but you can still rebuild and defragment them. Select the bloated tables and choose Optimize table from the same dropdown. For InnoDB this performs a recreate-and-analyze that reclaims the data_free space you measured earlier and refreshes index statistics so the query planner makes better choices.
Follow optimization with Analyze table on your busiest feed and comment tables. Stale index statistics are a common cause of queries that were fast last month and crawl today, because the planner estimates row counts from outdated samples. If the slow-query behavior you discovered in the earlier feed-loading work persists after analysis, inspect the indexes directly. On a table's Structure tab, open the Indexes panel and confirm that columns used in mooSocial's WHERE and ORDER BY clauses, such as user_id and created_at on feed tables, are indexed. You can add a missing composite index through phpMyAdmin's Add index dialog without any command line, but only do so on confirmed hot paths, since every extra index slows writes and adds to the bloat you just cleared.
Resolving Connection Errors and Preventing Recurrence
Connection failures on shared hosting are almost always resource ceilings rather than configuration faults. Each mooSocial page view opens a database connection, and shared plans cap concurrent connections per user. When a traffic burst coincides with long-running unindexed queries, connections pile up and new requests are refused with the familiar database-connection error. The first lever is query efficiency, which the repair and indexing steps above address directly. The second is reducing how often mooSocial hits the database at all, achieved through its built-in caching in the AdminCP under Settings > Site Settings, where enabling cache and a sensible cache lifetime cuts redundant reads substantially.
Verify your credentials have not drifted. mooSocial reads them from config/database.php in your document root, and a password reset in cPanel's MySQL Databases screen that was not mirrored into that file produces a persistent connection error unrelated to load. Open the file in File Manager, confirm the host, user, and database match the cPanel values, and never change the host to anything other than localhost on standard shared accounts. If PHP itself is throwing mysqli warnings, check the error_log file in your document root or the account's Errors view in cPanel; those messages distinguish a credential problem from a resource limit at a glance.
Make maintenance recurring rather than reactive. Since you cannot schedule server-side cron for MySQL directly, use cPanel's Cron Jobs to trigger a small PHP script in your account that runs the same scoped notification and session deletes on a weekly schedule, keeping each batch under the limits described earlier. Pair that with a monthly manual optimize pass in phpMyAdmin and a quarterly review of the information-schema size query. This rhythm keeps a growing mooSocial community within shared-hosting limits and prevents the slow slide back into bloat, crashed tables, and the connection errors that follow.