mysql8容量_MySQL8.0内存相关参数总结
MySQL理论上使⽤的内存 = 全局共享内存 + max_connections×线程独享内存。
也就是：innodb_buffer_pool_size + innodb_log_buffer_size + thread_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+ binlog_cache_size+tmp_table_size)
下⾯我们按照全局内存参数与线程独享参数分类，简单介绍下相关参数的作⽤。
全局共享内存
innodb_buffer_pool_size
innodb_buffer_pool_size这个参数是对Mysql数据库最重要的参数之⼀，它对 InnoDB 存储引擎的作⽤类似于 Key Buffer Cache 对MyISAM 存储引擎的影响，主要区别是 InnoDB Buffer Pool 不仅仅缓存索引数据，会缓存表的数据，⽽且完全按照数据⽂件中的数据快结构信息来缓存，这⼀点和 Oracle SGA 中的 database buffer cache 类似，因此在SHOW ENGINE innodb status中查到的Buffer pool size要乘以16K。
可以通过 (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算得到 InnoDB Buffer Pool 的命中率。
innodb_change_buffering
change buffering是MySQL5.5加⼊的新特性，change buffering是insert buffer的加强，insert buffer只针对insert有效，change buffering对insert、delete、update(delete+insert)、purge都有效。当修改⼀个索引块(secondary index)时的数据时，索引块在buffter pool中不存在，修改信息就会被cache在change buffer中，当通过索引扫描把需要的索引块读取到buffer pool时，会和change buffer中修改信息合并，再择机写回disk。
⽬的还是为了减少随机IO带来性能损耗，说明⽩了：把随机IO尽量变成顺序IO。现在SSD盛⾏，在SSD上随机访问和顺序访问性能⼏乎差不多的情况下，change buffering特性不会带来多⼤的性能提升，但对于廉价的机械硬盘，这个参数还是能帮助提⾼性能的。
change buffering由参数innodb_change_buffering控制:
all:  buffer inserts, delete-marking operations, and purges.
none:  Do not buffer any operations.
inserts:  Buffer insert operations.
deletes:  Buffer delete-marking operations.
changes:  Buffer both inserts and delete-marking.
purges:  Buffer the physical deletion operations that happen in the background.
注意这个内存是在Innodb的buffer pool中分配的，计算总内存的时候不⽤算它。
innodb_change_buffer_max_size
表⽰change buffer在buffer pool中的最⼤占⽐，默认25%，最⼤50%。如果系统中有严重的insert、update并且还有活跃的delete时，就增⼤max_size；针对不更改数据的纯报表系统，可以减⼩该参数值。
innodb_log_buffer_size
这是 InnoDB 存储引擎的事务⽇志所使⽤的缓冲区。为了提⾼性能，也是先将信息写⼊ Innofb Log Buffer 中，当满⾜
innodb_flush_log_trx_commit 参数所设置的相应条件(或者⽇志缓冲区写满)之后，才会将⽇志写到⽂件(或者同步到磁盘)中。
innodb_flush_log_trx_commit 参数可以设置为0，1，2，解释如下：
0：log buffer中的数据将以每秒⼀次的频率写⼊到logfile中，且同时会进⾏⽂件系统到磁盘的同步操作，但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者⽂件系统到磁盘的刷新操作，该模式速度最快，但不太安全，mysqld进程的崩溃会导致上⼀秒钟所有事务数据的丢失；
1：在每次事务提交的时候将log buffer 中的数据都会写⼊到logfile，同时也会触发⽂件系统到磁盘的同步，该模式是最安全的，但也是最慢的⼀种⽅式；
2：事务提交会触发log buffer 到logfile的刷新，但并不会触发磁盘⽂件系统到磁盘的同步，该模式速度较快，也⽐0安全，只有在操作系统崩溃或者系统断电的情况下，上⼀秒钟所有事务数据才可能丢失。
thread_cache_size
线程池缓存⼤⼩，当客户端断开连接后将当前线程缓存起来，当在接到新的连接请求时快速响应⽆需创建新的线程 。这尤其对那些使⽤短连接的应⽤程序来说可以极⼤的提⾼创建连接的效率。可以通过(Connections - Threads_created) / Connections * 100% 计算出连接线程缓存的命中率。也可以通过
如下⼏个MySQL状态值来适当调整线程池的⼤⼩：
mysql> show global status like 'Thread%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_cached | 2 |
| Threads_connected | 1 |
| Threads_created | 3 |
| Threads_running | 2 |
+-------------------+-------+
4 rows in set (0.01 sec)
当 Threads_cached 越来越少 但 Threads_connected 始终不降，且 Threads_created 持续升⾼，可适当增加 thread_cache_size 的⼤⼩。
table_open_cache
table_open_cache指定表⾼速缓存的⼤⼩，⽤来缓存表⽂件的⽂件句柄信息。当我们的客户端程序提交Query给MySQL的时候，MySQL 需要对Query所涉及到的每⼀个表都取得⼀个表⽂件句柄信息，如果没有Table Cache，那么MySQL就不得不频繁的进⾏打开关闭⽂件操作，⽆疑会对系统性能产⽣⼀定的影响，每当MySQL访问⼀个表时，如果在表缓冲区中还有空间，该表就被打开并放⼊其中，这样可以更快地访问表内容。注意，这⾥设置的是可以缓存的表⽂件句柄信息的数⽬，⽽不是内存空间的⼤⼩。
通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_open_cache的值。其中Open_tables是当前正在打开表的数量，Opened_tables是所有已经打开表的数量。注意，不能盲⽬地把table_open_cache设置成很⼤的值，设置太⼤超过了shell的⽂件描述符(通过ulimit -n查看)，造成⽂件描述符不⾜，从⽽造成性能不稳定或者连接失败。如果发现open_tables等于
table_open_cache，并且opened_tables在不断增长，那么你就需要增加table_open_cache的值了(上述状态值可通过SHOW GLOBAL STATUS LIKE 'Open%tables'获得)。如果Open_tables的值已经接近
table_cache的值，且Opened_tables还在不断变⼤，则说明mysql 正在将缓存的表释放以容纳新的表，此时可能需要加⼤table_cache的值。对于⼤多数情况，⽐较适合的值：
Open_tables / Opened_tables >= 0.85
Open_tables / table_cache <= 0.95
建议把MySQL数据库放在⽣产环境中试运⾏⼀段时间，然后把参数的值调整得⽐Opened_tables的数值⼤⼀些，并且保证在⽐较⾼负载的极端条件下依然⽐Opened_tables略⼤。
table_definition_cache
table_definition_cache和table_open_cache类似，前者缓存frm⽂件，关于后者，⽂档中并没有说明，应该是ibd/MYI/MYD；
状态值：
Open_table_definitions：表定义⽂件.frm被缓存的数量
Opened_table_definitions：历史上总共被缓存过的,frm⽂件数量
key_buffer_size
key_buffer_size指定索引缓冲区的⼤⼩，它决定索引处理的速度，尤其是索引读的速度。通过检查状态值Key_read_requests和
Key_reads，可以知道key_buffer_size设置是否合理。⽐例key_reads /key_read_requests应该尽可能的低，⾄少是1:100，1:1000更好(上述状态值可以使⽤SHOW STATUS LIKE ‘key_read%'获得)。key_buffer_size只对MyISAM表起作⽤。即使你不使⽤MyISAM 表，但是内部的临时磁盘表是MyISAM表，也要使⽤该值。可以使⽤检查状态值created_tmp_disk_tables得知详情。
提交更改是内存条吗max_connections
MySQL的最⼤连接数，增加该值增加mysqld 要求的⽂件描述符的数量。如果服务器的并发连接请求量⽐较⼤，建议调⾼此值，以增加并⾏连接数量，当然这建⽴在机器能⽀撑的情况下，因为如果连接数越多，介于MySQL会为每个连接提供连接缓冲区，就会开销越多的内存，所以要适当调整该值，不能盲⽬提⾼设值。数值过⼩会经常出现ERROR 1040: Too many connections错误，可以过'conn%'通配符查看当前状态的连接数量，以定夺该值的⼤⼩。max_used_connections / max_connections * 100% (理想值≈ 85%) 如果
max_used_connections跟max_connections相同 那么就是max_connections设置过低或者超过服务器负载上限了，低于10%则设置过⼤。
线程/会话/连接独享内存
binlog_cache_size
为每个session 分配的内存，在事务过程中⽤来存储⼆进制⽇志的缓存，可以提⾼记录bin-log的效率，默认32K，没有⼤事务，dml也不是很频繁的情况下可以设置⼩⼀点，如果事务⼤⽽且多，dml操作也频繁，则可以适当的调⼤⼀点。
数据库binlog_cache_size的使⽤情况，可以查看：Binlog_cache_disk_use表⽰因为我们binlog_cache_size设计的内存不⾜导致缓存⼆进制⽇志⽤到了临时⽂件的次数，Binlog_cache_use  表⽰ ⽤binlog_cache_size缓存的次数
tmp_table_size和max_heap_table_size
tmp_table_size规定了内部内存临时表的最⼤值，每个线程都要分配。(实际起限制作⽤的是tmp_table_size和max_heap_table_size的最⼩值。)如果内存临时表超出了限制，MySQL就会⾃动地把它转化为基于磁盘的MyISAM表，存储在指定的tmpdir⽬录下，默认:
mysql> show variables like "tmpdir";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| tmpdir | /tmp/ |
+---------------+-------+
优化查询语句的时候，要避免使⽤临时表，如果实在避免不了的话，要保证这些临时表是存在内存中的。如果需要的话并且你有很多group by语句，并且你有很多内存，增⼤tmp_table_size(和max_heap_table_size)的值。这个变量不适⽤与⽤户创建的内存表(memory table)。
可以⽐较内部基于磁盘的临时表的总数和创建在内存中的临时表的总数(Created_tmp_disk_tables和Created_tmp_tables)，⼀般的⽐例关系是:
Created_tmp_disk_tables/Created_tmp_tables<5%
max_heap_table_size定义了⽤户可以创建的内存表(memory table)的⼤⼩.这个值⽤来计算内存表的最⼤⾏数值。这个变量⽀持动态改变，即set @max_heap_table_size = xxx。
以上就是MySQL8.0内存相关参数总结的详细内容，更多关于mysql8.0 内存参数的资料请关注脚本之家其它相关⽂章！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。