Why MySQL Memory Stays High and How to Optimize It

1. MySQL Memory Composition

MySQL memory usage consists of two main parts: global memory shared by the entire instance (e.g., InnoDB Buffer Pool, Adaptive Hash Index, Table Cache) and per‑session thread memory allocated for each connection (e.g., sort_buffer_size, join_buffer_size, read_buffer_size). Additional memory may be used by storage engines, plugins, and custom functions.

Important note: many MySQL memory areas, such as the Buffer Pool, are pre‑allocated and remain resident, so they are not released back to the OS even when activity drops.

2. Why MySQL Memory Rises and Doesn't Drop

Memory often stays high not because of leaks but due to MySQL's caching design: the Buffer Pool is pre‑allocated (typically 60‑80% of total RAM), connection caches like thread cache retain resources, and the operating system may keep page cache even after MySQL releases memory.

Therefore, a stable instance with memory that stops growing is not necessarily abnormal.

3. How to Diagnose High Memory Usage

1. Are There Many Connections?

Each connection consumes thread memory; hundreds or thousands of idle connections can significantly increase memory usage.

Check: total and active connection counts in database monitoring.

If connections remain high, consider read‑write splitting to reduce load on the primary.

2. Are There Many Slow or Large Queries?

Large queries (full table scans, ORDER BY + LIMIT without indexes) trigger temporary tables and large sort buffers, inflating memory usage.

Check: slow‑query statistics and temporary file usage in monitoring.

Download and optimize slow SQL statements; this reduces memory pressure and improves overall performance.

3. Is Business Load Too High?

Rapid growth in workload without adjusting database resource quotas can exhaust memory.

Recommendation: Align resource packages with business growth to maintain stability.

4. Platform Efforts: Choosing a Better Memory Allocator

We investigated MySQL memory allocators and switched the default to jemalloc for better fragmentation rates, reclamation strategies, and thread‑cache cleaning, similar to its use in high‑performance systems like Redis.

1. Why Choose jemalloc?

Lower memory fragmentation, especially under high concurrency.

Improved memory reclamation with thread‑cache cleanup.

Widely adopted in high‑performance software.

2. Comparison After Introduction

After adopting jemalloc, memory no longer continuously climbs; it converges according to business pressure, improving overall stability.

New MySQL instances now default to jemalloc, and we are gradually migrating existing instances to benefit from higher resource efficiency and service stability.

5. Summary and Recommendations

MySQL prioritizes performance and maximal caching, which makes its memory usage appear greedy but not necessarily wasteful. Understanding these mechanisms helps make calm, professional decisions when facing high memory usage.

Key recommendations:

Do not obsess over unreleased memory; focus on stability.

Optimize slow queries and control connection counts as primary steps.

Regularly assess database pressure and adjust resource packages accordingly.

Continue platform‑side optimizations such as improving memory allocators to enhance efficiency while preserving performance.