•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.3.3.5, “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, thus avoiding the normal slow memory allocation and freeing. Memory is allocated only for unexpectedly large strings. 

•For each table having BLOB  columns, a buffer is enlarged dynamically to read in larger BLOB  values. If you scan a table, the buffer grows as large as the largest BLOB  value. 

•MySQL requires memory and descriptors for the table cache. Handler structures for all in-use tables are saved in the table cache and managed as “First In, First Out”  (FIFO). The table_open_cache system variable defines the initial table cache size; see Section 8.4.3.1, “How MySQL Opens and Closes Tables” . 

MySQL also requires memory for the table definition cache. The table_definition_cache  system variable defines the number of table definitions that can be stored in the table definition cache. If you use a large number of tables, you can create a large table definition cache to speed up the opening of tables. The table definition cache takes less space and does not use file descriptors, unlike the table cache. 

•A FLUSH 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. FLUSH TABLES  does not return until all tables have been closed. 

•The server caches information in memory as a result of GRANT , CREATE USER , CREATE SERVER , and INSTALL PLUGIN  statements. This memory is not released by the corresponding REVOKE , DROP USER , DROP SERVER , and UNINSTALL PLUGIN  statements, so for a server that executes many instances of the statements that cause caching, there is an increase in cached memory use unless it is freed with FLUSH PRIVILEGES . 

•In a replication topology, the following settings affect memory usage, and can be adjusted as required: 

•The max_allowed_packet  system variable on a replication source limits the maximum message size that the source sends to its replicas for processing. This setting defaults to 64M. 

•The slave_pending_jobs_size_max  system variable on a multithreaded replica sets the maximum amount of memory that is made available for holding messages awaiting processing. This setting defaults to 128M. The memory is only allocated when needed, but it might be used if your replication topology handles large transactions sometimes. It is a soft limit, and larger transactions can be processed. 

•The rpl_read_size  system variable on a replication source or replica controls the minimum amount of data in bytes that is read from the binary log files and relay log files. The default is 8192 bytes. A buffer the size of this value is allocated for each thread that reads from the binary log and relay log files, including dump threads on sources and coordinator threads on replicas. 

•The binlog_transaction_dependency_history_size  system variable limits the number of row hashes held as an in-memory history. 

•The max_binlog_cache_size  system variable specifies the upper limit of memory usage by an individual transaction. 

•The max_binlog_stmt_cache_size  system variable specifies the upper limit of memory usage by the statement cache. 

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 

