Mr Papa said
in file sp-site-support-functions.php, around line 160 find and comment out this code:
        $wpdb->hide_errors();
        set_error_handler(‘sp_construct_php_error’);
comment out both lines

For the record, this allowed me to activate the plugin and have a dozen or so members help me run a test by replying to a topic all at once with server levels never rising above 1.5± and she’s holding steady at ≤0.5 for nearly a half hour.

Progress is a good thing. The only downside right now should be that I’m not logging errors, right?

How can we work together to make these LIKE queries a bit more multisite friendly in future versions?

At least our forums are back online!

yeah, 5.5.x is pretty recent…  just wanted to make sure it was near what we do most of our testing at…

Andy and will talk more about it, but still surprised a bit, but we do not test on anything like 11k tables…  we do test on overall db size much larger than yours, but who knows…

yes, not logging errors… generally thats okay…  we dont see very many real errors – just useful when debugging one…  and the issue for you appears to be harmless notices…

so let us discuss…  will let you know if you can try anything for us…

out of curiosity, is your dba able to do an explain on one of those show tables like query and collect the data from it?  would show the steps mysql is going through (ie temp tables, etc)…

Steve has opened up a discussion and we are already discussing possible alternatives to the way we check this but… for the record – performing a SHOW TABLE query is not, itself, inherently time or resource consuming. All this query does is to determine if the table actually exists and to do this it simply looks in the catalogue of tables.

Now – unless something has changed dramatically – the catalogue of tables is held permanently in the mySQL cache memory (RAM) and does not involve a normal database traversion.

The important thing to look for in the error log entries (and by this I mean the server php error log) is not the SHOW TABLE entries but the error entry immediately before the SHOW TABLE entries as this will most usually be the one that is causing the problem.

Mr Papa said
…is your dba able to do an explain on one of those show tables like query and collect the data from it? 

Not at the time, since we were just monitoring top processes after activating the plugin and loads spiked too quickly to do much before I deactivated it.

Thank you both for the the additional input. I’ll run it by my sysadmn to see if he has any feedback.

Yellow Swordfish said
The important thing to look for in the error log entries is… the error entry immediately before the SHOW TABLE entries

I know the PHP notices are just an inconsequential nuisance, but for what it’s worth here are the error log entries from my testing yesterday immediately preceding numerous SHOW TABLES LIKE queries like the ones I posted earlier…

[05-Nov-2013 17:59:26 UTC] PHP Notice: Undefined index: forumname
[05-Nov-2013 17:59:27 UTC] PHP Notice: Undefined index: forumname
[05-Nov-2013 17:59:27 UTC] PHP Notice: Undefined index: forumname

the php log error is pretty pointless…  no clue where its from…  forumname is used in bunch of spots…  our error log will include the file and location too… but think that has already been fixed…