CONCEPT Cited by 1 source

MySQL memory instrumentation¶

MySQL memory instrumentation is the subset of performance_schema that measures how much memory is allocated + what it's for at server-internal granularity. Each memory-consuming subsystem (SQL parser, optimizer, sort buffers, InnoDB buffer pool, THD session state, replication, FULLTEXT index build) is registered as a separate memory instrument with a memory/<subsystem>/<name> identifier.

(Source: sources/2026-04-21-planetscale-profiling-memory-usage-in-mysql.)

Discovery¶

Memory instruments live in performance_schema.setup_instruments alongside wait / stage / statement instruments. Total instrument count in a typical MySQL 8 install is ~1,255. Filter to memory:

SELECT name, documentation
  FROM performance_schema.setup_instruments
  WHERE name LIKE 'memory/%';

There are several hundred memory categories. A minority carry non-NULL documentation; many are self-describing by name only. Canonical undocumented example flagged by Dicken: memory/sql/Filesort_buffer::sort_keys — the instrument that dominates a large ORDER BY on an unindexed column, but documentation IS NULL.

Summary tables¶

Memory accounting is exposed via five sibling tables keyed on granularity:

memory_summary_by_account_by_event_name — per (user, host)
memory_summary_by_host_by_event_name — per client host
memory_summary_by_thread_by_event_name — per server thread
memory_summary_by_user_by_event_name — per MySQL user
memory_summary_global_by_event_name — server-wide

See concepts/memory-profiling-granularity for the five-way split's implications (notably: no per-query granularity exists natively).

Columns of interest¶

Each row in a memory_summary_* table tracks counters per (grain_key, event_name):

CURRENT_COUNT_USED — live allocations not yet freed
CURRENT_NUMBER_OF_BYTES_USED — live bytes (the column the profiling workflow samples)
HIGH_COUNT_USED / HIGH_NUMBER_OF_BYTES_USED — historical peaks since the instrument was enabled
SUM_NUMBER_OF_BYTES_ALLOC / SUM_NUMBER_OF_BYTES_FREE — cumulative alloc/free totals

Canonical profiling query from the Dicken post:

SELECT event_name, current_number_of_bytes_used
  FROM performance_schema.memory_summary_by_thread_by_event_name
  WHERE thread_id = YOUR_THREAD_ID
  ORDER BY current_number_of_bytes_used DESC;

Seen in¶

PlanetScale's Profiling memory usage in MySQL (2024-04-11). Ben Dicken uses setup_instruments + the memory_summary_by_thread_by_event_name table as the canonical entrypoint for per-query memory diagnosis, via concepts/per-thread-memory-profiling. (Source: sources/2026-04-21-planetscale-profiling-memory-usage-in-mysql.)

Caveats¶

Instrument count + naming vary across MySQL minor versions.
Many memory instruments have documentation IS NULL — name is the only hint.
Enabling more instruments increases performance_schema memory overhead.
In-memory storage engine — no persistence across restarts.