CONCEPT Cited by 1 source

Memory profiling granularity¶

Memory profiling granularity is the set of keys a memory accounting system aggregates allocations by. MySQL's performance_schema exposes five fixed granularities — account, host, thread, user, global — via five sibling memory_summary_*_by_event_name tables.

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

The five tables¶

Granularity	Table	Keyed on
account	`memory_summary_by_account_by_event_name`	`(user, host)` tuple
host	`memory_summary_by_host_by_event_name`	client host
thread	`memory_summary_by_thread_by_event_name`	server thread id
user	`memory_summary_by_user_by_event_name`	MySQL user
global	`memory_summary_global_by_event_name`	server-wide total

All five share the same event_name column (a memory instrument) and the same byte-counter columns (current_number_of_bytes_used, high_number_of_bytes_used, etc.). Only the grouping key differs.

Canonical gap: no per-query grain¶

Dicken canonicalises the gap verbatim: "Notice that there is no specific tracking for memory usage at a per-query level. However, this does not mean we cannot profile the memory usage of a query!" The per-thread grain is the canonical substitute because MySQL binds one query to one connection to one thread for the query's lifetime, so per-thread memory on the thread running your query is per-query memory for the duration of that query — see concepts/per-thread-memory-profiling.

Why no per-query grain?¶

The post doesn't explain MySQL's design choice, but the pragmatic reason is cost: tagging every malloc with the currently-executing statement id + maintaining a counter table keyed on statement id would multiply per-allocation overhead. Thread-level accounting is essentially free because the thread handle is already on hand when memory is allocated.

When the grain matters¶

Account / user / host: tenant-level accounting on multi-tenant MySQL instances.
Thread: the canonical grain for per-query / per-connection profiling.
Global: capacity planning + fleet-level anomaly detection.

Seen in¶

PlanetScale's Profiling memory usage in MySQL (2024-04-11). Dicken lists all five tables + names the per-query gap + selects the by_thread_by_event_name table as the canonical substitute. (Source: sources/2026-04-21-planetscale-profiling-memory-usage-in-mysql.)