The following list indicates some of the ways that the mysqld server uses memory. Where applicable, the name of the system variable relevant to the memory use is given:
All threads share the
key buffer; its size is determined by the
Other buffers used by the server are allocated as needed.
See Section 7.8.2, “Tuning Server Parameters”.
Each thread that is used to manage client connections uses some thread-specific space. The following list indicates these and which variables control their size:
The connection buffer and result buffer each begin with a
size equal to
but are dynamically enlarged up to
max_allowed_packet bytes as
needed. The result buffer shrinks to
after each SQL statement. While a statement is running, a
copy of the current statement string is also allocated.
All threads share the same base memory.
When a thread is no longer needed, the memory allocated to it is released and returned to the system unless the thread goes back into the thread cache. In that case, the memory remains allocated.
MyISAM tables are memory mapped. This is
because the 32-bit memory space of 4GB is not large enough
for most big tables. When systems with a 64-bit address
space become more common, we may add general support for
Each request that performs a sequential scan of a table
allocates a read buffer (variable
When reading rows in an arbitrary sequence (for example,
following a sort), a random-read
be allocated to avoid disk seeks.
All joins are executed in a single pass, and most joins can
be done without even using a temporary table. Most temporary
tables are memory-based hash tables. Temporary tables with a
large row length (calculated as the sum of all column
lengths) or that contain
columns are stored on disk.
One problem before MySQL 3.23.2 is that if an internal
in-memory temporary table becomes too large, the error
The table occurs. From 3.23.2 on, MySQL handles this
automatically by changing the table from in-memory to
on-disk format, to be handled by the
MyISAM storage engine. To work around
this problem for older servers, you can increase the
temporary table size by setting the
tmp_table_size option to
mysqld, or by setting the SQL option
sql_big_tables in the client program. See
Section 7.7.4, “How MySQL Uses Internal Temporary Tables”, and
Section 5.1.3, “Server System Variables”.
In MySQL 3.20, the maximum size of the temporary table is
record_buffer*16; if you are using this
version, you have to increase the value of
record_buffer. You can also start
mysqld with the
--big-tables option to always
store temporary tables on disk. However, this affects the
speed of many complicated queries.
Most requests that perform a sort allocate a sort buffer and zero to two temporary files depending on the result set size. See Section B.5.4.4, “Where MySQL Stores Temporary Files”.
Almost all parsing and calculating is done in thread-local and reusable memory pools. No memory overhead is needed for small items, so the normal slow memory allocation and freeing is avoided. Memory is allocated only for unexpectedly large strings.
ISAM table that is opened, the index file
is opened once and the data file is opened once for each
concurrently running thread. For each concurrent thread, a
table structure, column structures for each column, and a
buffer of size
are allocated (where
N is the maximum row length, not
BLOB columns). A
BLOB column requires five to
eight bytes plus the length of the
BLOB data. The
storage engines maintain one extra row buffer for internal
Handler structures for all in-use tables are saved in a
cache and managed as a FIFO. The initial cache size is taken
from the value of the
variable. If a table has been used by two running threads at
the same time, the cache contains two entries for the table.
See Section 7.7.2, “How MySQL Opens and Closes Tables”.
TABLES statement or mysqladmin
flush-tables command closes all tables that are
not in use at once and marks all in-use tables to be closed
when the currently executing thread finishes. This
effectively frees most in-use memory.
TABLES does not return until all tables have been
The server caches information in memory as a result of
GRANT statements. This memory
is not released by the corresponding
REVOKE statements, so for a
server that executes many instances of the statements that
cause caching, there will be an increase in memory use. This
cached memory can be freed with
ps and other system status programs may
report that mysqld uses a lot of memory. This
may be caused by thread stacks on different memory addresses.
For example, the Solaris version of ps counts
the unused memory between stacks as used memory. To verify this,
check available swap with
swap -s. We test
mysqld with several memory-leakage detectors
(both commercial and Open Source), so there should be no memory