mysql内存参数分类大全

一、线程独享内存

在MySQL中，线程独享内存主要用于各客户端连接线程存储各种操作的独享数据，如线程栈信息，分组排序操作，数据读写缓冲，结果集暂存等等，而且大多数可以通过相关参数来控制内存的使用量。

* 线程栈信息使用内存(thread_stack)：
主要用来存放每一个线程自身的标识信息，如线程id，线程运行时基本信息等等，我们可以通过 thread_stack 参数来设置为每一个线程栈分配多大的内存。
Global,No Dynamic,Default 192K(32bit), 256K(32bit),
推荐配置：默认

* 排序使用内存(sort_buffer_size)：
MySQL 用此内存区域进行排序操作(filesort)，完成客户端的排序请求。当我们设置的排序区缓存大小无法满足排序实际所需内存的时候，MySQL会将数据写入磁盘文件来完成排序。由于磁盘和内存的读写性能完全不在一个数量级，
所以sort_buffer_size参数对排序操作的性能影响绝对不可小视。排序操作的实现原理请参考：MySQL Order By的实现分析。
什么时候会用到？
对结果集排序时
使用确认：
可以通过查询计划中的Extra列的值为Using file-sort来证实使用了和这个缓冲区。
>explain select * from user1;
Global Session,Dynamic,Default 2M(32bit), 2M(32bit),
推荐配置：8M（内存足够的情况下），默认（内存紧张的情况）
优化建议：一种说法是增大可以提高order by,group by性能，防止数据写入磁盘占用IO资源，还有一种说法是不推荐增加这个缓冲区的大小，理由是当值太大时可能会降低查询的执行速度。目前我没有实验证实。

* Join操作使用内存(join_buffer_size)：
应用程序经常会出现一些两表（或多表）Join的操作需求，MySQL在完成某些Join需求的时候（all/index join），为了减少参与Join的“被驱动表”的读取次数以提高性能，需要使用到Join Buffer来协助完成Join操作
（具体Join实现算法请参考：MySQL中的 Join 基本实现原理）。当Join Buffer太小，MySQL 不会将该Buffer存入磁盘文件，而是先将Join Buffer中的结果集与需要Join的表进行Join操作，然后清空Join Buffer中的数据，
继续将剩余的结果集写入此Buffer中，如此往复。这势必会造成被驱动表需要被多次读取，成倍增加IO访问，降低效率。
什么时候会用到？
当查询必须连接两个表（或多个）的数据集并且不能使用索引时，这个缓冲区会被用到。这个缓冲区专门为每个线程的无索引链接操作准备的。
使用确认：
可以通过查询计划中的Extra列的值为Using join bufer来证实使用了和这个缓冲区。
>explain select * from user1;
+------+-------------+-------+-------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+-------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | user1 | index | NULL | name | 78 | NULL | 3 | Using index |
+------+-------------+-------+-------+---------------+------+---------+------+------+-------------+
Global Session,Dynamic,Default 128K 各版本平台最大值不一样
推荐配置：8M（内存足够的情况下），默认（内存紧张的情况）
优化建议：有一种说法是增加这个缓冲区的大小不会加快全连接操作的速度。目前我没有实验证实。

* 顺序读取数据缓冲区使用内存(read_buffer_size)：
这部分内存主要用于当需要顺序读取数据的时候，如无法使用索引的情况下的全表扫描，全索引扫描等。在这种时候，MySQL按照数据的存储顺序依次读取数据块，每次读取的数据快首先会暂存在read_buffer_size中，
当buffer空间被写满或者全部数据读取结束后，再将buffer中的数据返回给上层调用者，以提高效率。
Global Session,Dynamic,Default 128K
推荐配置：4M/8M * 随机读取数据缓冲区使用内存(read_rnd_buffer_size)：
和顺序读取相反，当MySQL进行非顺序读取（随机读取）数据块的时候，会利用这个缓冲区暂存读取的数据。如根据索引信息读取表数据，根据排序后的结果集与表进行Join等等。
总的来说，就是当数据块的读取需要满足一定的顺序的情况下，MySQL就需要产生随机读取，进而使用到read_rnd_buffer_size 参数所设置的内存缓冲区。
Global Session,Dynamic,Default 256K
推荐配置：8M * 连接信息及返回客户端前结果集暂存使用内存(net_buffer_lenth)：
这部分用来存放客户端连接线程的连接信息和返回客户端的结果集。当MySQL开始产生可以返回的结果集，会在通过网络返回给客户端请求线程之前，会先暂存在通过net_buffer_lenth所设置的缓冲区中，
等满足一定大小的时候才开始向客户端发送，以提高网络传输效率。不过net_buffer_lenth参数所设置的仅仅只是该缓存区的初始化大小，MySQL会根据实际需要自行申请更多的内存以满足需求，
但最大不会超过 max_allowed_packet 参数大小。
Global Session,Dynamic,Default 16K
推荐配置：默认 16K

* 批量插入暂存使用内存(bulk_insert_buffer_size)：
当我们使用如 insert … values(…),(…),(…)… 的方式进行批量插入的时候，MySQL会先将提交的数据放如一个缓存空间中，当该缓存空间被写满或者提交完所有数据之后，MySQL才会一次性将该缓存空间中的数据写入数据库并清空缓存。
此外，当我们进行 LOAD DATA INFILE操作来将文本文件中的数据Load进数据库的时候，同样会使用到此缓冲区。
Global Session,Dynamic,Default 8M
推荐配置：默认 8M
* 临时表使用内存(tmp_table_size)：
当我们进行一些特殊操作如需要使用临时表才能完成的Order By,Group By 等等，MySQL可能需要使用到临时表。当我们的临时表较小（小于tmp_table_size 参数所设置的大小）的时候，MySQL会将临时表创建成内存临时表，
只有当tmp_table_size所设置的大小无法装下整个临时表的时候，MySQL才会将该表创建成MyISAM存储引擎的表存放在磁盘上。不过，当另一个系统参数 max_heap_table_size 的大小还小于 tmp_table_size 的时候，
MySQL将使用 max_heap_table_size 参数所设置大小作为最大的内存临时表大小，而忽略tmp_table_size 所设置的值。而且 tmp_table_size 参数从 MySQL 5.1.2 才开始有，之前一直使用 max_heap_table_size。
谁小谁生效.另外还有一个参数max_tmp_tables,没有使用
tmp_table_size
Global Session,Dynamic,Default 16M
推荐配置：64M
max_heap_table_size
Global Session,Dynamic,Default 8M
This variable sets the maximum size to which user-created MEMORY tables are permitted to grow
这个变量定义了MEMORY存储引擎表的最大容量。
This variable is also used in conjunction with tmp_table_size to limit the size of internal in-memory tables. See
这个变量也与tmp_table_size一起使用限制内部内存表的大小。请见
http://dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html
推荐配置：64M
主要根据业务以及服务器内存来调整，如果有需要到则可以调整到。GB居然使用2G的配置，汗

目前没有一个简便的方式来确定内部临时表的总容量。可以通过MySQL状态变量created_tmp_tables和created_tmp_disk_tables来确定创建了临时表和基于磁盘的临时表
mysql> show global status like 'create%tables';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
| Created_tmp_tables | 0 |
+-------------------------+-------+
5.5中，可以使用PERFORMANCE—SCHEMA来帮助统计基于磁盘的临时表的总大小

补充说明：上面所列举的MySQL线程独享内存仅仅只是所有线程独享内存中的部分，并不是全部，只是这些可能对MySQL的性能产生较大的影响，且可以通过系统参数进行调节。
由于以上内存都是线程独享，极端情况下的内存总体使用量将是所有连接线程的总倍数。所以在设置过程中一定要谨慎，切不可为了提升性能就盲目的增大各参数值，
避免因为内存不够而产生Out Of Memory异常或者是严重的Swap交换反而降低整体性能。

二、全局共享内存

全局共享内则主要是MySQL Instance以及底层存储引擎用来暂存各种全局运算及可共享的暂存信息，如
存储查询缓存的 Query Cache，
缓存连接线程的 Thread Cache，
缓存表文件句柄信息的 Table Cache，
缓存二进制日志的 BinLog Buffer，
缓存MyISAM存储引擎索引键的 Key Buffer
存储InnoDB数据和索引的 InnoDB Buffer Pool
等等。下面针对 MySQL 主要的共享内存进行一个简单的分析。

* MyISAM索引缓存 Key Buffer（key_buffer_size）：
MyISAM 索引缓存将MyISAM表的索引信息（.MYI文件）缓存在内存中，以提高其访问性能。这个缓存可以说是影响MyISAM存储引擎性能的最重要因素之一了，通过 key_buffere_size 设置可以使用的最大内存空间。
注意：即使运行一个全部采用innodb的模式，仍需要定义一个索引码缓冲区，因为MYSQL元信息与MyISAM定义相同。
Global ,Dynamic,Default 8M
推荐配置：默认 8M
如何确认key_buffer_size不够用？
使用show full proceslist的State列中，值Repairing the keycache是一个明显的指标，它指出当前索引码缓冲区大小不足以执行当前运行的SQL语句。这将导致额外的磁盘I/O开销。

* 查询缓存 Query Cache （query_cache_size）：
http://dev.mysql.com/doc/refman/5.5/en/query-cache-configuration.html
http://dev.mysql.com/doc/refman/5.5/en/query-cache-status-and-maintenance.html
查询缓存是MySQL比较独特的一个缓存区域，用来缓存特定Query的结果集（Result Set）信息，且共享给所有客户端。通过对Query语句进行特定的Hash计算之后与结果集对应存放在Query Cache中，以提高完全相同的Query语句的相应速度。
当我们打开MySQL的Query Cache之后，MySQL接收到每一个SELECT类型的Query之后都会首先通过固定的Hash算法得到该Query的Hash值，然后到Query Cache中查找是否有对应的Query Cache。如果有，则直接将Cache的结果集返回给客户端。
如果没有，再进行后续操作，得到对应的结果集之后将该结果集缓存到Query Cache中，再返回给客户端。当任何一个表的数据发生任何变化之后，与该表相关的所有Query Cache全部会失效，所以Query Cache对变更比较频繁的表并不是非常适用，
但对那些变更较少的表是非常合适的，可以极大程度的提高查询效率，如那些静态资源表，配置表等等。为了尽可能高效的利用Query Cache，MySQL针对Query Cache设计了多个query_cache_type值
和两个Query Hint：SQL_CACHE和SQL_NO_CACHE。当query_cache_type设置为0（或者 OFF）的时候不使用Query Cache，当设置为1（或者 ON）的时候，当且仅当Query中使用了SQL_NO_CACHE 的时候MySQL会忽略Query Cache，
当query_cache_type设置为2（或者DEMAND）的时候，当且仅当Query中使用了SQL_CACHE提示之后，MySQL才会针对该Query使用Query Cache。可以通过query_cache_size来设置可以使用的最大内存空间。
Global Dynamic,Default 0
推荐配置：16M
如何确定系统query cache的情况？
show global status like 'Qcache%';或者
select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like 'Qcache%';
公式：
（Qcache_hits/Qcache_hits+Com_select+1)*100来确定查询缓存的有效性
mysql> show variables like 'query_cache_size';
+------------------+----------+
| Variable_name | Value |
+------------------+----------+
| query_cache_size | 16777216 |
+------------------+----------+
1 row in set (0.00 sec)
mysql> show global status like 'Qcache%';
+-------------------------+------------+
| Variable_name | Value |
+-------------------------+------------+
| Qcache_free_blocks | 535 |
| Qcache_free_memory | 4885448 |
| Qcache_hits | 1858574835 |
| Qcache_inserts | 1619931831 |
| Qcache_lowmem_prunes | 802889469 |
| Qcache_not_cached | 825000679 |
| Qcache_queries_in_cache | 4411 |
| Qcache_total_blocks | 9554 |
+-------------------------+------------+
8 rows in set (0.00 sec)
mysql> show global status like 'Com_select';
+---------------+------------+
| Variable_name | Value |
+---------------+------------+
| Com_select | 2445037535 |
+---------------+------------+
1 row in set (0.00 sec) * 连接线程缓存 Thread Cache（thread_cache_size）：
连接线程是MySQL为了提高创建连接线程的效率，将部分空闲的连接线程保持在一个缓存区以备新进连接请求的时候使用，这尤其对那些使用短连接的应用程序来说可以极大的提高创建连接的效率。
当我们通过thread_cache_size设置了连接线程缓存池可以缓存的连接线程的大小之后，可以通过(Connections - Threads_created) / Connections * 100% 计算出连接线程缓存的命中率。
注意，这里设置的是可以缓存的连接线程的数目，而不是内存空间的大小。
Global,Dynamic,Default 0
推荐配置：8个
如何确定系统Thread Cache的情况？
mysql> show global status like 'Threads_created';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| Threads_created | 506 |
+-----------------+-------+
1 row in set (0.00 sec)

mysql> show global status like 'connections';
+---------------+----------+
| Variable_name | Value |
+---------------+----------+
| Connections | 16513711 |
+---------------+----------+
1 row in set (0.00 sec)
16513711-506/16513711 * 100% =99.9938% 很高的命中率啊这台之只读的slave * 表缓存 Table Cache（table_open_cache）：
表缓存区主要用来缓存表文件的文件句柄信息，在 MySQL5.1.3之前的版本通过table_cache参数设置，但从MySQL5.1.3开始改为table_open_cache来设置其大小。当我们的客户端程序提交Query给MySQL的时候，
MySQL需要对Query所涉及到的每一个表都取得一个表文件句柄信息，如果没有Table Cache，那么MySQL就不得不频繁的进行打开关闭文件操作，无疑会对系统性能产生一定的影响，Table Cache 正是为了解决这一问题而产生的。
在有了Table Cache之后，MySQL每次需要获取某个表文件的句柄信息的时候，首先会到Table Cache中查找是否存在空闲状态的表文件句柄。如果有，则取出直接使用，没有的话就只能进行打开文件操作获得文件句柄信息。
在使用完之后，MySQL会将该文件句柄信息再放回Table Cache 池中，以供其他线程使用。注意，这里设置的是可以缓存的表文件句柄信息的数目，而不是内存空间的大小。
Global,Dynamic,Default 400
推荐配置：根据内存配置4G 2048 大于最大Opened_tables
如何确定系统table_open_cache的情况？
mysql> show variables like 'table_open_cache';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| table_open_cache | 512 |
+------------------+-------+
1 row in set (0.00 sec)
mysql> show global status like 'open%_tables';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 512 |
| Opened_tables | 6841 |
+---------------+-------+
2 rows in set (0.00 sec)
调优参考：
http://blog.zfcms.com/article/282
http://www.kuqin.com/database/20120815/328904.html
两个参数的值。其中Open_tables是当前正在打开表的数量，Opened_tables是所有已经打开表的数量。
如果Open_tables的值已经接近table_cache的值，且Opened_tables还在不断变大，则说明mysql正在将缓存的表释放以容纳新的表，此时可能需要加大table_cache的值。对于大多数情况，比较适合的值：
Open_tables / Opened_tables >= 0.85
Open_tables / table_cache <= 0.95
如果对此参数的把握不是很准，VPS管理百科给出一个很保守的设置建议：把MySQL数据库放在生产环境中试运行一段时间，然后把参数的值调整得比Opened_tables的数值大一些，并且保证在比较高负载的极端条件下依然比Opened_tables略大。
在mysql默认安装情况下，table_cache的值在2G内存以下的机器中的值默认时256到 512，如果机器有4G内存,则默认这个值是2048，

* 表定义信息缓存 Table definition Cache （table_definition_cache）：
表定义信息缓存是从 MySQL5.1.3 版本才开始引入的一个新的缓存区，用来存放表定义信息。当我们的 MySQL 中使用了较多的表的时候，此缓存无疑会提高对表定义信息的访问效率。
MySQL 提供了 table_definition_cache 参数给我们设置可以缓存的表的数量。注意，这里设置的是可以缓存的表定义信息的数目，而不是内存空间的大小。
The number of table definitions (from .frm files) that can be stored in the definition cache. If you use a large number of tables, you can create a large table definition cache to speed up opening of tables.
Global, Dynamic, Default 400
推荐配置：根据内存配置4G 2048 和Table Cache一样即可

* 二进制日志缓冲区Binlog Cache( binlog_cache_size）：
二进制日志缓冲区主要用来缓存由于各种数据变更操做所产生的 Binary Log 信息。为了提高系统的性能，MySQL 并不是每次都是将二进制日志直接写入 Log File，而是先将信息写入 Binlog Buffer 中，
当满足某些特定的条件（如 sync_binlog参数设置）之后再一次写入 Log File 中。我们可以通过 binlog_cache_size 来设置其可以使用的内存大小，同时通过 max_binlog_cache_size 限制其最大大小
（当单个事务过大的时候 MySQL 会申请更多的内存）。当所需内存大于 max_binlog_cache_size 参数设置的时候，MySQL 会报错：“Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage”。
Global,Dynamic,Default 32K
推荐配置：2M

* InnoDB 日志缓冲区 InnoDB Log Buffer （innodb_log_buffer_size）：
这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写入 Innofb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间。
注：innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0，1，2，解释如下：

0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操作，但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操作；
1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步；
2：事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作。
此外，MySQL文档中还提到，这几种设置中的每秒同步一次的机制，可能并不会完全确保非常准确的每秒就一定会发生同步，还取决于进程调度的问题。实际上，InnoDB 能否真正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制，可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经完成了磁盘同步。

Global,Dynamic,Default 8M
推荐配置：8M 默认

* InnoDB 数据和索引缓存 InnoDB Buffer Pool（innodb_buffer_pool_size）：
InnoDB Buffer Pool 对 InnoDB 存储引擎的作用类似于 Key Buffer Cache 对 MyISAM 存储引擎的影响，主要的不同在于 InnoDB Buffer Pool 不仅仅缓存索引数据，还会缓存表的数据，
而且完全按照数据文件中的数据快结构信息来缓存，这一点和 Oracle SGA 中的 database buffer cache 非常类似。所以，InnoDB Buffer Pool 对 InnoDB 存储引擎的性能影响之大就可想而知了。
可以通过 (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算得到 InnoDB Buffer Pool 的命中率。
global级别，不可动态变更 Default 128M
设置InnoDB数据和索引内存缓存空间大小
配置方式：配置文件中配置
选择参数：50 - 80 % RAM

mysql> show variables like '%innodb_buffer%';
+------------------------------+-----------+
| Variable_name | Value |
+------------------------------+-----------+
| innodb_buffer_pool_instances | 1 |
| innodb_buffer_pool_size | 268435456 |
+------------------------------+-----------+
2 rows in set (0.00 sec)
通过show global status和show engine innodb status/G的BUFFER POOL AND MEMORY
mysql> show global status like '%innodb_buffer%';
+---------------------------------------+--------------+
| Variable_name | Value |
+---------------------------------------+--------------+
| Innodb_buffer_pool_pages_data | 15684 |
| Innodb_buffer_pool_bytes_data | 256966656 |
| Innodb_buffer_pool_pages_dirty | 210 |
| Innodb_buffer_pool_bytes_dirty | 3440640 |
| Innodb_buffer_pool_pages_flushed | 372378403 |
| Innodb_buffer_pool_pages_free | 1 |
| Innodb_buffer_pool_pages_misc | 698 |
| Innodb_buffer_pool_pages_total | 16383 |
| Innodb_buffer_pool_read_ahead_rnd | 0 |
| Innodb_buffer_pool_read_ahead | 691803 |
| Innodb_buffer_pool_read_ahead_evicted | 41350 |
| Innodb_buffer_pool_read_requests | 170965099291 |
| Innodb_buffer_pool_reads | 5392513 |
| Innodb_buffer_pool_wait_free | 0 |
| Innodb_buffer_pool_write_requests | 5825388207 |
+---------------------------------------+--------------+
15 rows in set (0.01 sec)

mysql> show engine innodb status/G
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 274726912; in additional pool allocated 0
Dictionary memory allocated 4055091
Buffer pool size 16383
Free buffers 1
Database pages 15673
Old database pages 5765
Modified db pages 521
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 27497746, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 6346456, created 1902566, written 372381712
0.00 reads/s, 0.37 creates/s, 27.75 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 15673, unzip_LRU len: 0
I/O sum[1107]:cur[0], unzip sum[0]:cur[0]
命中率 Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100%
170965099291-5392513/170965099291 × 100% = 99.99%

* InnoDB 字典信息缓存 InnoDB Additional Memory Pool（innodb_additional_mem_pool_size）:
InnoDB 字典信息缓存主要用来存放 InnoDB 存储引擎的字典信息以及一些 internal 的共享数据结构信息。所以其大小也与系统中所使用的 InnoDB 存储引擎表的数量有较大关系。不过，如果我们通过 innodb_additional_mem_pool_size 参数所设置的内存大小不够，InnoDB 会自动申请更多的内存，并在 MySQL 的 Error Log 中记录警告信息。
global级别，不可动态变更 Default 8M
设置InnoDB存放数据库字典信息的Buffer大小
推荐配置：50M

三、查看统计

1.查看各参数内存配置方式
#全局共享内存 9个变量
show variables like 'innodb_buffer_pool_size'; /* InnoDB 数据和索引缓存（InnoDB Buffer Pool） */
show variables like 'innodb_additional_mem_pool_size'; /* InnoDB 字典信息缓存（InnoDB Additional Memory Pool）*/
show variables like 'innodb_log_buffer_size'; /* InnoDB 日志缓冲区（InnoDB Log Buffer） */
show variables like 'binlog_cache_size'; /* 二进制日志缓冲区（Binlog Buffer）*/
show variables like 'thread_cache_size'; /* 连接线程缓存（Thread Cache）*/
show variables like 'query_cache_size'; /* 查询缓存（Query Cache）*/
show variables like 'table_open_cache'; /* 表缓存（Table Cache） */
show variables like 'table_definition_cache'; /* 表定义信息缓存（Table definition Cache） */
show variables like 'key_buffer_size'; /* MyISAM索引缓存（Key Buffer） */
#最大线程数
show variables like 'max_connections';
#线程独享内存 6个变量
show variables like 'thread_stack'; /* 线线程栈信息使用内存(thread_stack) */
show variables like 'sort_buffer_size'; /* 排序使用内存(sort_buffer_size) */
show variables like 'join_buffer_size'; /* Join操作使用内存(join_buffer_size) */
show variables like 'read_buffer_size'; /* 顺序读取数据缓冲区使用内存(read_buffer_size) */
show variables like 'read_rnd_buffer_size'; /* 随机读取数据缓冲区使用内存(read_rnd_buffer_size) */
show variables like 'tmp_table_size'; /* 临时表使用内存(tmp_table_size) ，我实际计算把tmp_table_size放入全局共享内*/
也可以通过系统变量的方式直接获取
select @@key_buffer_size;
select @@max_connections 2.mysql内存计算公式
mysql使用的内存 = 全局共享内存+最大线程数×线程独享内存
mysql used mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size
+max_connections*（
thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size+tmp_table_size）

SET @kilo_bytes=1024;
SET @mega_bytes=@kilo_bytes*1024;
SET @giga_bytes=@mega_bytes*1024;
SELECT (@@innodb_buffer_pool_size+@@innodb_additional_mem_pool_size+@@innodb_log_buffer_size+@@binlog_cache_size+@@thread_cache_size+@@query_cache_size+@@table_open_cache+@@table_definition_cache+@@key_buffer_size+@@max_connections*(@@thread_stack+@@sort_buffer_size+@@join_buffer_size+@@read_buffer_size+@@read_rnd_buffer_size+@@tmp_table_size))/@giga_bytes AS MAX_MEMORY_GB;

这个理论最大的内存使用量，在5.5版本中tmp_table_size默认是16M，按默认u自大连接数151计算，光线程独享的临时表占据的空间都是2416M，我实际计算把tmp_table_size放入全局共享内
我的计算公式
mysql使用的内存 = 全局共享内存+最大线程数×线程独享内存
mysql used mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size+tmp_table_size
+max_connections*（
thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size）

内存参数：

一、线程独享内存

二、全局共享内存

三、查看统计

相关阅读