MySQL临时表在很多场景中都会用到,比如用户自己创建的临时表用于保存临时数据,以及MySQL内部在执行复杂SQL时,需要借助临时表进行分组、排序、去重等操作。下面将会对MySQL临时表的一些概念、分类和常见问题进行整理。
MySQL临时表类型
1.外部临时表,通过create temporary table语法创建的临时表,可以指定存储引擎为memory,innodb, myisam等等,这类表在会话结束后,会被自动清理。如果临时表与非临时表同时存在,那么非临时表不可见。show tables命令不显示临时表信息。
可通过information_schema.INNODB_TEMP_TABLE_INFO系统表可以查看外部临时表的相关信息,这部分使用的还是比较少。
2.内部临时表,通常在执行复杂SQL,比如group by, order by, distinct, union等,执行计划中如果包含Using temporary,还有undo回滚的时候,但空间不足的时候,MySQL内部将使用自动生成的临时表,以辅助完成工作。
MySQL临时表相关参数
1.max_heap_table_size:用户创建的内存表的最大值,也用于和tmp_table_size一起,限制内部临时表在内存中的大小。
2.tmp_table_size:内部临时表在内存中的的最大值,与max_heap_table_size参数共同决定,取二者的最小值。如果临时表超过该值,就会从内存转移到磁盘上。
3.innodb_tmpdir:online ALTER TABLE operations that rebuild the table max_tmp_tables
4.default_tmp_storage_engine:外部临时表(create temporary table创建的表)默认的存储引擎。
5.innodb_temp_data_file_path:innodb引擎下temp文件属性。建议限制innodb_temp_data_file_path = ibtmp1:1G:autoextend:max:30G
6.Internal_tmp_disk_storage_engine:磁盘上的内部临时表存储引擎,可选值为myisam或者innodb。使用innodb表在某些场景下,比如临时表列太多,或者行大小超过限制,可能会出现“ Row size too large or Too many columns”的错误,这时应该将临时表的innodb引擎改回myisam。tmpdir:临时表目录,当临时表大小超过一定阈值,就会从内存转移到磁盘上,
7.tmpdir变量表示磁盘上临时表所在的目录。
MySQL临时表相关状态变量
1.Created_tmp_disk_tables:执行SQL语句时,MySQL在磁盘上创建的内部临时表数量,如果这个值很大,可能原因是分配给临时表的最大内存值较小,或者SQL中有大量排序、分组、去重等操作,SQL需要优化。
2.Created_tmp_files:创建的临时表数量
3.Created_tmp_tables:执行SQL语句时,MySQL创建的内部临时表数量。
4.Slave_open_temp_tables statement 或则 mix模式下才会看到有使用。
slave_open_temp_tables 的值显示,通过复制,当前slave创建了多少临时表,binlog_format只能是statement 和 mixed 下有效.
备注:stop slave 也没有用,必须主库手动删除 或则 session退出 才可以。
以下是从库binlog记录信息:
MySQL临时表注意事项
1.MySQL临时表可能导致磁盘可用空间减少:
在MySQL5.7版本之前,临时表的存储引擎默认为myisam,myisam临时表在SQL执行结束后,会自动删除临时表。然而从5.7版本开始,临时表的默认存储引擎变为innodb,虽然在性能上有了一定的提升,但是由于innodb引擎的临时表共用表空间ibtmp1,导致在高并发下,多个session同时创建临时表时,该表空间会变得非常大,并且不能动态缩小,除非重启MySQL,否则无法释放。
可以为临时表空间设置一个最大值,比如10G,如下:
innodb_temp_data_file_path = ibtmp1:128M:autoextend:max:10G
当临时表空间达到最大值10G时,SQL执行将会报错,影响应用的正常执行。
对于临时表空间过大的问题,通常也有一些其他方法解决,比如:
将临时表的存储引擎设置为myisam,虽然可能有一些性能问题,但不会导致磁盘空间问题。
2.SQL语句:
(1)加上合适的索引
(2)在where条件中过滤更多的数据
(3)重写SQL,优化执行计划
(4)如果不得不使用临时表,那么一定要减少并发。建议使用SSD硬盘。
3.undo相关
1)使用innodb_rollback_segments配置选项定义回滚segment的数量,默认设置是128,也是最大值。一个回滚segment总是分配给系统表空间,32个回滚segment预留给临时表空间(ibtmp1)。因此,要分配回滚段来撤消表空间,将innodb_rollback_segments设置为大于33的值。配置单独的undo表空间时,system表空间中的回滚段将呈现为非活动状态。
就是说超过128回滚segement的时候,就需要临时表出来救急。
tablespace -> segment -> extent(64个page,1M) -> page(16kb)
2)truncate undo
当innodb_undo_log_truncate触发的时候,undo表空间截断操作在服务器日志目录中创建一个临时的undo_space_number_trunc.log文件,该日志目录由innodb_log_group_home_dir定义。如果在truncate操作期间发生系统故障,临时日志文件允许启动进程识别被截断的undo表空间,并继续操作。
4.binlog 缓存相关
使用二进制日志缓存并且值达到了binlog_cache_size设置的值,用临时文件存储来自事务的变化这样的事务数量。可通过Binlog_stmt_cache_disk_use状态变量中单独跟踪。
总结
1.从上述了解来看MySQL临时表,平时的监控和优化是避免不了的。
2.除此之外,在业务实现中也可以适当的使用,如作为中间表临时保存少量信息 等。
3.在复制环节中binlog_format等于ROW模式时,临时表相关是不记录binlog日志的(除了drop命令),这部分需要注意。