Gregory, thanks for the warning. The toolserver will not work for this - its using MySQL 5, which optimizes everything very differently. Plus it is using views instead of tables - again, there are some optimization bugs associated with that. This really has to be on the main wiki - this way we could even compare a large wiki vs a small wiki query optimizations.
It probably wouldn't be a huge security risk to open up a slave to this, but I don't expect it to happen anytime soon.
I guess we can make a list of prohibited fields/tables.
The only feasible option.
What if there was a standalone MySQL ~4.0.29 database somewhere that had loaded an Enwiki pages-meta-history.xml database dump, and which allowed people to run EXPLAIN queries on it via a web interface - wouldn't that mostly solve the problem?
By definition, we know/assume that the dumps do not contain confidential information - so rather than trying to enumerate data that needs protection, this way there is simply no sensitive data there in the first place to protect.
And in the web interface for running the EXPLAIN queries, there could also be a big "RESET" button that would copy over backups of the MySQL data files, thus resetting the database back to a known state if it became messed up somehow.
Disclaimer: I don't personally feel any desire to build such a thing, I'm just trying to understand whether it would solve the problem or not.
-- All the best, Nick.