inspect.getCandidateUniqueKeys avoidably slow on large schemas

[twotwotwo]

I'm looking at gh-ost for use on a multitenant app where we have tens thousands of tables on one server. Because number of tables and columns, a couple of inspect.go INFORMATION_SCHEMA queries take more than a minute.

It looks like for getCandidateUniqueKeys' big query, the slowness is easy to fix: the ON clause on the join checks that TABLE_SCHEMA and TABLE_NAME match, when that isn't necessary because in the inner and outer queries both check for the right TABLE_NAME and TABLE_SCHEMA in their WHERE clauses. Without those additional conditions, MySQL 5.6 is able to run the query in seconds.

Without the change we'd spend hours just on gh-ost startup time on every migration. With that change and -skip-foreign-key-checks, it's much more workable for us. I have a simple change ready that I'll submit as a PR; writing here because the PR instructions suggest starting discussions on issues.

[shlomi-noach]

closed by #699 and #701 . Thank you!