Thoughts on the new PERFORMANCE_SCHEMA in MySQL

Peter Gulutzan and Mark Leith have both written about the new PERFORMANCE_SCHEMA in MySQL. I’ve read through the worklog, or most of it – there were some spots where Firefox seemed to start overlaying parts with other parts, quite weird. But anyway I’ve read as much as I can.

Obviously many people have been putting a ton of thought into this for years, and I can’t pretend to judge their work in a single sitting. But I have opinions nevertheless.

If the implementation turns out to be as good as the initial swing at it looks, this is a great development. This is the way things should be done – this is, finally, the level of detail of instrumentation other databases have. There’s a lot of complexity; it is a large worklog and I can’t say whether it’s complete or something is put in the wrong place or will turn out to be not quite what’s needed; that’s where I stop trying to form an opinion. But overall, this is just a great development.

A few questions and comments, though.

  • Why has this not been public? You put four years of work into this without any community input? What a shame.
  • Mark says “There’s no stats for InnoDB yet, though I can’t see that lasting for long.” I can. Why don’t you see InnoDB being slow to add support for it?
  • What version is this intended for? 6.x is kind of vague after four years of work.
  • Information by itself is no use unless you can act on it. I predict that a lot of neglected bug reports will get revisited if this information can be brought to bear on it. I also predict that if implemented fully, this will show people where the hot spots in their server are; and yet they’ll be unable to fix them.

I'm Baron Schwartz, the founder and CEO of VividCortex. I am the author of High Performance MySQL and lots of open-source software for performance analysis, monitoring, and system administration. I contribute to various database communities such as Oracle, PostgreSQL, Redis and MongoDB. More about me.