So recently discovered my install of WP was running slower and seemingly slower as of late, pretty much maybe since version 4.3.x somewhere, possibly 4.4.x either way. It wasn’t until recently I was digging through my logs for other reasons, and I noticed a massive amount of entries similar to the below error (although much wordier I just truncated it for the sake of demonstration.
mod_fcgid: stderr: WordPress database error Table 'blah.wp_termmeta' doesn't exist for query SELECT.....
The problem is or was rather, that no method of attempting to repair and or rebuild the table fixed the issue. Using WordPress built in method of putting the following in your wp-config.php file and then going to your-domain.com/wp-admin/maint/repair.php to attempt to fix the problem would tell me the table is missing, and failed to repair it or rebuild it.
Going into MySQL directly through phpMyAdmin also failed to fix it.
So what I ended up doing was going to the WordPress master .sql and finding the bit that was specifically the table to be created, and attempted to use that. Which also failed at first, but did end up working in the end.
Even though I can not proof 100% that the issue was related to a naming convention of some sort without actually digging into the files more. I was able to figure out that for whatever reason my table prefix was the issue in creating the table. When I used my custom prefix no method worked for repairing or creating the table. But when I used WP’s stock prefix, instantly it worked. Then all I did was go in and alter my tables name to match the prefix I use.
I am putting this out there just incase anyone else runs into the same issue. I know there are a handful of posts about this already but none of them mention anything about the prefix possibly being the issue.
CREATE TABLE `wp_termmeta` ( `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `term_id` bigint(20) unsigned NOT NULL DEFAULT '0', `meta_key` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL, `meta_value` longtext COLLATE utf8mb4_unicode_ci, PRIMARY KEY (`meta_id`), KEY `term_id` (`term_id`), KEY `meta_key` (`meta_key`(191)) ) ENGINE=InnoDB AUTO_INCREMENT=3255 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
An additional step I took prior to using the stock prefix although feel it has no bearing on the outcome but worth mentioning is I went out and installed the “WordPress Beta Developer” plugin and opt into the nightly build beta version, and upgraded to that as well.