https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html
tmp_table_size默认16M。tmp_table_size如果过小,存不下了就会存到磁盘上。对于group by会有性能影响。
下面的sql EXPLAIN 如下,出现了Using temporary。表示查询会利用临时表。
在默认tmp_table_size大小16M下执行:
查看临时表统计信息,Created_tmp_disk_tables 为0,Created_tmp_tables 为1表示上诉sql执行后生产了一张内存里的临时表。
将tmp_table_size 调从16M调整为16K
再次执行,查询时间从4变成了18秒
重新统计
再次查看status,这次有在磁盘上创建1个临时表。
设置为32M
Percona Server中的临时表信息会记录到慢查询日志
由于MySQL慢查询日志里没有使用临时表的信息,这就给我们诊断性能问题带来了一些不便,第三方的版本如Percona Server,在慢查询里可以有更详细的信息,将会记录临时表使用的情况,从而有助于我们诊断和调优。
mysql8中对临时表有较大的优化
临时表引擎使用innodb(default 磁盘)和temptable(default 内存)
mysql临时表空间满了的原因如下。1、根据官网文档的解释,在正常关闭或初始化中止时,将删除临时表空间,并在每次启动服务器时重新创建,重启能够释放空间的原因在于正常关闭数据库,临时表空间就被删除了,重新启动后重新创建,也就是重启引发了临时表空间的重建,重新初始化,所以,重建后的大小为12M。
2、对临时表空间的大小进行限制,允许自动增长,但最大容量有上限。
以MySQL 8.0 来说,通过查看 8.0 的官方文档得知,8.0 的临时表空间分为会话临时表空间和全局临时表空间,会话临时表空间存储用户创建的临时表和当 InnoDB 配置为磁盘内部临时表的存储引擎时由优化器创建的内部临时表,当会话断开连接时,其临时表空间将被截断并释放回池中;也就是说,在 8.0 中有一个专门的会话临时表空间,当会话被杀掉后,可以回收磁盘空间;而原来的 ibtmp1 是现在的全局临时表空间,存放的是对用户创建的临时表进行更改的回滚段,在 5.7 中 ibtmp1 存放的是用户创建的临时表和磁盘内部临时表;
也就是在 8.0 和 5.7 中 ibtmp1 的用途发生了变化,5.7 版本临时表的数据存放在 ibtmp1 中,在 8.0 版本中临时表的数据存放在会话临时表空间,如果临时表发生更改,更改的 undo 数据存放在 ibtmp1 中;
实验验证:将之前的查询结果保存成临时表,对应会话是 45 号,通过查看对应字典表,可知 45 号会话使用了 temp_8.ibt 这个表空间,通过把查询保存成临时表,可以用到会话临时表空间,如下图:
下一步杀掉 45 号会话,发现 temp_8.ibt 空间释放了,变为了初始大小,状态为非活动的,证明在 mysql8.0 中可以通过杀掉会话来释放临时表空间。
总结:在 mysql5.7 时,杀掉会话,临时表会释放,但是仅仅是在 ibtmp 文件里标记一下,空间是不会释放回 *** 作系统的。如果要释放空间,需要重启数据库;在 mysql8.0 中可以通过杀掉会话来释放临时表空间。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)