CONCEPT Cited by 1 source

MySQL `performance_schema`¶

performance_schema is MySQL's built-in instrumentation subsystem — a database containing ~113 tables that expose server-internal telemetry: per-statement timing, per-stage execution timing, per-index table-I/O counts, lock waits, thread state, and much more. It's implemented as an in-memory storage engine (PERFORMANCE_SCHEMA), so data lives only in RAM and is lost on restart.

(Source: sources/2026-04-21-planetscale-identifying-and-profiling-problematic-mysql-queries.)

What's in it¶

PlanetScale's Ben Dicken reports "113" tables via:

SELECT COUNT(*) FROM information_schema.tables
  WHERE table_schema = 'performance_schema';

Load-bearing tables referenced by the post:

events_statements_summary_by_digest — per-query-digest aggregates: COUNT_STAR, SUM_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT, SUM_LOCK_TIME. Units: picoseconds.
table_io_waits_summary_by_index_usage — per-(table, index) row read counts; the row with INDEX_NAME IS NULL counts reads that bypassed every index.
events_statements_history_long — recent statement executions with thread_id, statement_id, event_id, end_event_id.
events_stages_history_long — recent per-stage timings (stage/sql/executing, stage/sql/optimizing, stage/sql/Opening tables, ...); used for concepts/query-stage-profiling.
threads — maps PROCESSLIST_ID to thread_id (required to join the history tables to a specific connection).
setup_instruments, setup_consumers, setup_actors — control tables that gate which instrumentation is active.

Enablement¶

Typically on by default:

SHOW VARIABLES LIKE 'performance_schema';
-- +--------------------+-------+
-- | Variable_name      | Value |
-- +--------------------+-------+
-- | performance_schema | ON    |
-- +--------------------+-------+

Can be disabled on memory-constrained hosts — "all of the information it tracks is stored in an in-memory PERFORMANCE_SCHEMA storage engine" — but most production MySQL deployments keep it enabled because the observability it provides vastly exceeds its memory cost.

Relationship to `sys` schema¶

The sys schema (concepts/mysql-sys-schema) is a curated set of views + stored procedures sitting on top of performance_schema that present the same data in human-readable form. Everything sys exposes is backed by performance_schema; sys is ergonomics, not a separate source of truth.

Caveats¶

In-memory — no persistence across restarts; no long-term trend storage without an exporter.
Overhead — enabling instruments + consumers + history has measurable cost; the PlanetScale post explicitly flags "(small) adverse effect on the overall performance of your system" when enabling history globally.
Timer unit is picoseconds — divide by 1e12 for seconds. This is an easy source of 1000× misreads.
Version-dependent — number of tables and exact schema vary across MySQL releases.

Seen in¶

PlanetScale's field manual for query diagnosis (2024-03-29). Dicken walks through events_statements_summary_by_digest as the "which queries are expensive?" entry point, then drills via table_io_waits_summary_by_index_usage for per-table unindexed-read diagnosis, then into stage-timing via events_stages_history_long. Also frames PlanetScale Insights as the productised successor — same underlying data, better UX. (Source: sources/2026-04-21-planetscale-identifying-and-profiling-problematic-mysql-queries.)

MySQL performance_schema¶