Use SHOW commands and performance_schema views to inspect server-wide and per-component memory allocations in MySQL.
Staying under available RAM prevents swapping, keeps queries fast, and avoids server crashes. Continuous visibility lets you resize buffers and tune queries early.
Issue SHOW VARIABLES LIKE '%buffer%size';
to list all core caches. Focus on innodb_buffer_pool_size
, key_buffer_size
, and query_cache_size
.
performance_schema.memory_summary_global_by_event_name
reports current bytes allocated per engine component. Sort by current_alloc
to locate the biggest consumers.
SELECT event_name, current_alloc/1024/1024 AS mbFROM performance_schema.memory_summary_global_by_event_nameORDER BY current_alloc DESCLIMIT 10;
Combine performance_schema
and information_schema.processlist
to see per-thread memory. Join on THREAD_ID
and ID
for precise attribution.
Yes. Wrap business queries—like retrieving customer order totals—in performance_schema.setup_instruments
to capture their memory footprint without altering application logic.
Enable performance_schema
at startup, export metrics to Prometheus, and set warning thresholds. Resize buffers gradually and test under load.
Relying only on OS tools hides internal fragmentation. Forgetting to divide bytes into MB leads to misinterpretation of numbers.
Overhead is usually <5 %, especially when you leave optional consumers disabled. The insight gained outweighs the minor cost.
MySQL 8.0 and MariaDB 10.5+ include this view. Older versions require INFORMATION_SCHEMA.INNODB_SYS_MEMORY, or upgrade.
Yes. Use max_user_connections
and MEMORY
resource group controls, or run queries inside containers with cgroup limits.