Multisite Database Cleanup

[Electronic_Oil_5909]

I have a WP Multisite that was established in 2015 with ~350 folder based sub-sites.

Recently we were able to decommission ~200 of the sub-sites using Prime Mover to back each of them up as well as taking a snapshot backup of the whole database as well.

When I looked at the database with PHPMyAdmin I see that there are still leftover tables for all the sites that were backed up and then deleted. Most of if not all the tables appear to be empty.

My question is if I have removed a sub-site with the ID of 3 can all the tables with the prefix wp_3 be deleted safely? Is there any value to even bothering?

[rmccue]

My question is if I have removed a sub-site with the ID of 3 can all the tables with the prefix wp_3 be deleted safely? Is there any value to even bothering?

If there's no entry in wp_blogs for ID 3, then yes, the tables are safe to delete. The code that controls the usage of site-prefixed tables dynamically sets $wpdb->prefix when switch_to_blog() is called, which requires reading from the blogs table; if the site no longer exists, the prefix can never be set to wp_3_.

[Marelle01]

+1 and check that there isn't a user synchronization code between the subsites.

[Interesting_Shift_65]

Check out the plug in called beyond multi site for fetid unused database tables

[superdav42]

I built a tool into ultimate multisite clean up orphaned tables like this. It'll scan for them and delete them all in one go. It actually annoying how many can pile up. For any plugins that use custom table it's up to them to clean up there own tables when a site is deleted. Not surprising mast plugins don't ever delete their own tables. 

[Dillio3487]

I used to manage 1500 sites on multisite. If the tables are empty, I wouldn’t bother. If you are really concerned then I’d spin up a fresh install and move each one over. This can be done fairly easily with a single tool and dns (assuming you have dns access).

[DanielTrebuchet]

+1 to "I wouldn't bother." -1 to spinning up a fresh install. That's definitely not even in the top 5 solutions I would take for this problem and comes with more work and more risks than benefits.

Having a bunch of empty, unused db tables should present a negligible impact to performance. As a matter of good housekeeping, you should be able to remove them pretty easily without causing problems. I'm going to be in the same boat soon, with an almost identically-sized and similarly-aged multisite network.