Performance Schema is MySQL’s detailed instrumentation for statements, waits, and stages. Used lightly means you enable only the consumers you need, capture a short window of data, then disable the noisy ones again. On a busy small VPS it is a diagnostic session, not something you leave fully on all day.
When to turn it on
Turn it on when the slow query log and EXPLAIN still leave a mystery. Typical cases are lock waits, IO waits, or a spike you cannot pin to a single PHP path. On a VPS you can enable the relevant consumers, let them run for about an hour, export the tables you care about, and then turn the heavy consumers off. That keeps the cost bounded. On shared hosting you do not control Performance Schema, and you should not need to. Use staging and a plugin such as Query Monitor instead.
When to leave it alone
For a normal WordPress site on a small VPS, the slow query log plus EXPLAIN is usually enough. Save Performance Schema for a named question you cannot answer any other way. InnoDB status is available with SHOW ENGINE INNODB STATUS without enabling the full schema. If the server is already tight on memory, leaving every instrument enabled will not help stability.
What it actually records
Consumers write into tables in the performance_schema database. You will see statement history, wait events, mutex data, and stage timing. Each consumer has a real CPU and memory cost. Statement digest tables help answer “which query,” though the slow query log often covers that already. Wait events are the main reason to use the schema, because EXPLAIN does not show runtime locks or IO waits. Capture a short window, export the rows you need, then disable the consumer so history tables do not grow without limit on a small disk.
The sys schema views sit on top of Performance Schema and are easier to read. They cost whatever the underlying consumers cost, so the same rule applies: on for a look, then off. A small WordPress site should not carry that overhead overnight with no active investigation.
phpMyAdmin can browse performance_schema tables when they are enabled. Keep those sessions short, and avoid broad selects against large history tables. Read phpMyAdmin without fear before you run anything destructive in the wrong schema.
Tagged
Was this article helpful?
Be the first to rate this article.



