记一次生产MySQL服务器根目录满了的异常情况--DB临时表使用异常

最新推荐文章于 2022-12-21 20:15:00 发布

cuanjian2673

最新推荐文章于 2022-12-21 20:15:00 发布

阅读量345

点赞数

文章标签：数据库

tmp空间增长异常说明

作者：sylar版权所有[文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.]

一、背景说明

近日 zabbix总是如下报警信息：

二、问题分析

根据zabbix报警，立即查询空间，此时根目录空间较大，不至于报警

查看mysql的错误日志，发现该时间点有如下错误信息

根据上图错误提示，是tmp空间增长异常，并且是往里添加表（.myi格式结尾，且提及myisam，故做此判断）

查询数据库，确认是否有目录指向/tmp，根据下面截图得知/tmp目录是mysql临时表所在的目录

/tmp目录16M，最多可以创建32个，这个量完全够普通事物使用，需要具体定位什么情况需要这么大量的临时表，以至于超过该大小，使用到磁盘空间。

三、mysql内部临时表（in-memory和on-disk）

3.1内部临时表的定义

不同于手工创建的临时表，在sql执行过程中可能会用到临时文件存储查询结果，称为internal temporary table；该过程由Mysql自动完成，用户无法手工干预；
这些表或使用memory引擎存于内存，或使用MyISAM引擎存于磁盘；
当某些SQL命令在MySQL数据库中被执行的时候，它可能需要先创建一些内部的临时表来完成比较复杂的排序或分组查询。MySQL的临时表分为 in-memory 和 on-disk 两种。如有可能，MySQL 总是首先使用 in-memory 的临时表，而当临时表变得太大的时候，也可能被转存为on-disk 的临时表。

3.2内部临时表创建的源代码展示

MySQL源码如下所示

点击(此处)折叠或打开

代码地址：sql_select.cc:10229，函数：create_tmp_table()，位置：sql_select.cc:10557
/* If result table is small; use a heap */
/* future: storage engine selection can be made dynamic? */
if ( blob_count || using_unique_constraint
|| ( thd->variables .big_tables && !( select_options & SELECT_SMALL_RESULT ))
|| ( select_options & TMP_TABLE_FORCE_MYISAM ))
{
share->db_plugin = ha_lock_engine(0, myisam_hton);
table->file = get_new_handler( share, &table ->mem_root,
share->db_type ());
if (group &&
( param->group_parts > table-> file->max_key_parts () ||
param->group_length > table-> file->max_key_length ()))
using_unique_constraint=1;
}
else
{
share->db_plugin = ha_lock_engine(0, heap_hton);
table->file = get_new_handler( share, &table ->mem_root,
share->db_type ());
}

点击(此处)折叠或打开

代码地址：sql_select.cc:11224，函数：create_myisam_from_heap()，位置：sql_select.cc:11287
/*
copy all old rows from heap table to MyISAM table
This is the only code that uses record[1] to read/write but this
is safe as this is a temporary MyISAM table without timestamp/autoincrement
or partitioning.
*/
while (! table->file ->rnd_next( new_table.record [1]))
{
write_err= new_table .file-> ha_write_row(new_table .record[1]);
DBUG_EXECUTE_IF("raise_error" , write_err= HA_ERR_FOUND_DUPP_KEY ;);
if (write_err )
goto err ;
}

MySQL数据库用Created_tmp_tables 和Created_tmp_disk_tables 变量记录所用临时表的数目；

3.3内部临时表使用场景（in-memory和on-disk）

具体参考官方说明

内部临时表使用条件：http://dev.mysql.com/doc/refman/5.7/en/internal-temporary-tables.html
创建on-disk内部临时表会创建线程,具体说明详见下面链接：http://dev.mysql.com/doc/refman/5.5/en/general-thread-states.html

【官档小结】

以下条件可能导致SQL命令需要创建临时表：

使用了不同的 ORDER BY 和 GROUP BY 条件，或它们包含了JOIN查询中非首先表的字段；
同时使用了DISTINCT和ORDER BY;
如果SQL命令使用了SQLSMALLRESULT选项，那么需要时将创建in-memory临时表，除非查询中还包含有需用 on-disk 存储的元素；

一些条件下可能阻碍使用in-memory临时表, 导致MySQL改用on-disk临时表：

数据表中含有BLOB类型或TEXT类型字段列；
在GROUP BY或DISTINCT任何条件中含有超过512字节的列；
如果使用了UNION或UNION ALL，而且SELECT列中含有任何超过512字节的列；
如果in-memory临时表变得太大，超过tmptablesize或max_heaptablesize数值时；

四、分析具体SQL

根据zabbix报警的时间，摘取时间点前后发生的slow日志，详见下面日志
SQL.txt

执行该表，发现涉及到miubiserver数据库的慢查询，会极其耗费/tmp空间

 use miu_bi_server;
 SELECT
      COUNT(userName),weixin_follower.state,is_registered,weixin_number_info.`name`,company_sho   p.create_user,shop_province,shop_city
 FROM
      weixin_follower,weixin_number_info,weixin_follower_shop,company_shop
 WHERE
      createTime BETWEEN '2015-07-01 00:00:00'
 AND '2015-07-01 23:59:59'
 AND publicNO = original_id
 AND userName = follower_user_name
 AND weixin_follower_shop.organiz_id = shop_store_id
 GROUP BY weixin_number_info.`name`,weixin_follower.state,is_registered,company_shop.create_user,shop_province,shop_city;

这个事务执行结果是：2461 rows in set (6 min 8.32 sec)，在执行过程中，tmp空间增长如下。

可以看到最大能增长到1.7G，如果并行的很多这样的操作，可以解释为何tmp空间满了的原因

 [root@Wonhigh-Test14 tmp]# du -sh
 1.7G    .
 [root@Wonhigh-Test14 tmp]# du -sh
 909M    .
 [root@Wonhigh-Test14 tmp]# du -sh
 928M    .
 [root@Wonhigh-Test14 tmp]# du -sh
 978M    .
 [root@Wonhigh-Test14 tmp]# du -sh
 1.6G    
 [root@Wonhigh-Test14 tmp]# du -sh
 1.3G    .
 [root@Wonhigh-Test14 tmp]# du -sh
 348K.

查看后台线程，mysql官方说，如果开始使用磁盘临时表空间，会在后台开启线程

 [root@Wonhigh-Test14 ~]# lsof | grep tmp |more
 python     6380    woqu  mem       REG              202,3    1922533    1967165 /home/woqu/.python-eggs/M2Crypto-0.21.1-py2.7-linux-x86_64.egg-tmp/M2Crypto/__m2crypto.so
 python     6380    woqu  DEL       REG              202,3               7340085 /tmp/ffisXOHEc
 python     6380    woqu    8u      REG              202,3       4096    7340085 /tmp/ffisXOHEc (deleted)
 python     6381    woqu  mem       REG              202,3    1922533    1967165 /home/woqu/.python-eggs/M2Crypto-0.21.1-py2.7-linux-x86_64.egg-tmp/M2Crypto/__m2crypto.so
 python     6381    woqu  DEL       REG              202,3               7340086 /tmp/ffikSknto
 python     6381    woqu    8u      REG              202,3       4096    7340086 /tmp/ffikSknto (deleted)
 python     6382    woqu  mem       REG              202,3    1922533    1967165 /home/woqu/.python-eggs/M2Crypto-0.21.1-p
 y2.7-linux-x86_64.egg-tmp/M2Crypto/__m2crypto.so
 python     6382    woqu  DEL       REG              202,3               7340087 /tmp/ffidRwOPu
 python     6382    woqu    8u      REG              202,3       4096    7340087 /tmp/ffidRwOPu (deleted)
 python     6383    woqu  mem       REG              202,3    1922533    1967165 /home/woqu/.python-eggs/M2Crypto-0.21.1-py2.7-linux-x86_64.egg-tmp/M2Crypto/__m2crypto.so
 python     6383    woqu  DEL       REG              202,3               7340088 /tmp/ffixlIFZv
 python     6383    woqu    8u      REG              202,3       4096    7340088 /tmp/ffixlIFZv (deleted)
 java       6384    root  mem       REG              202,3      32768    7340082 /tmp/hsperfdata_root/6384
 python     6386    woqu  mem       REG              202,3    1922533    1967165 /home/woqu/.python-eggs/M2Crypto-0.21.1-py2.7-linux-x86_64.egg-tmp/M2Crypto/__m2crypto.so
 python     6386    woqu  DEL       REG              202,3               7340084 /tmp/ffiWPcba8
 python     6386    woqu    8u      REG              202,3       4096    7340084 /tmp/ffiWPcba8 (deleted)
 python     6387    woqu  DEL       REG              202,3               7340083 /tmp/ffi15zm6Z
 python     6387    woqu    8u      REG              202,3       4096    7340083 /tmp/ffi15zm6Z (deleted)
 bash       7761    root  cwd       DIR              202,3       4096    7340033 /tmp
 java      13263  hadoop  mem       REG              202,3      32768    7340045 /tmp/hsperfdata_hadoop/13263
 crond     18852    root  cwd       DIR              202,3       4096    7340033 /tmp
 java      22806  hadoop  mem       REG              202,3      32768    7340051 /tmp/hsperfdata_hadoop/22806
 java      24429  hadoop  mem       REG              202,3      32768    7340072 /tmp/hsperfdata_hadoop/24429
 java      26286    root  mem       REG              202,3      32768    7340089 /tmp/hsperfdata_root/26286
 mysqld    27317   mysql    5u      REG              202,3          0    7340041 /tmp/ibKPitK2 (deleted)
 mysqld    27317   mysql    6u      REG              202,3          0    7340057 /tmp/ibUu7CBU (deleted)
 mysqld    27317   mysql    7u      REG              202,3          0    7340058 /tmp/ibzvjNsM (deleted)
 mysqld    27317   mysql    8u      REG              202,3          0    7340059 /tmp/ibd0Npmw (deleted)
 mysqld    27317   mysql   13u      REG              202,3          0    7340060 /tmp/ib6O45to (deleted)
 mysqld    27317   mysql   41u      REG              202,3       1024    7340103 /tmp/#sql_6ab5_0.MYI
 mysqld    27317   mysql   43u      REG              202,3  832650804    7340104 /tmp/#sql_6ab5_0.MYD
 mysqld    27317   mysql   44u      REG              202,3   48077824    7340105 /tmp/#sql_6ab5_1.MYI
 mysqld    27317   mysql   45u      REG              202,3  387448832    7340106 /tmp/#sql_6ab5_1.MYD
 mongod    28986    root    7u     unix 0xffff8802079026c0        0t0      91268 /tmp/mongodb-10001.sock

此时看到磁盘临时表创建，并且使用量惊人，现在分析该SQL，为啥用这么多磁盘表空间，是否满足mysql创建磁盘临时表的条件。

该SQL有大量的groub by

这个视图创建，就需要耗费磁盘临时表，大量的union，并且含有text类型的列，满足创建磁盘临时表的条件。通过执行计划查看，用到临时表。且union很多。证实官方说法。

五、内部临时表优化以及建议

关于MySQL内部临时表（internal temporary table）的优化：

(1) 尽可能考虑如何避免SQL命令创建临时表

对于一个查询连接非常繁忙的数据库，频繁地使用需要创建临时表的查询本身就已经是一个性能瓶颈。需要重新检视您的数据表的结构以及各表之间的关联，重新考虑主键和索引，重组数据结构以减少应用中需不同的ORDER BY和GROUP BY的情况。

拆分为较少关联层次的多次查询，或使用View表。

因为目前线上发生的环境已经使用了view表，建议view表创建时候，根据业务需求，再创建，以减少 tmp消耗

(2)尽量设法确保临时表被创建于内存而非磁盘之中

如果实在是无法避免创建临时表，那么退而求其次，则需要尽量确保这些临时表能够被创建在内存之中。避免在结构设计和查询命令中使用BLOB和TEXT类型字段，或可考虑用 SUBSTRRING(colum,length)函数将其转换为字符串类型；用SQLSMALLRESULT选项通知数据库使用in-memory临时表；使用View来简化查询；使用RAM disk内存盘来存储MySQL 数据库的临时表（需确保无使用BLOB和TEXT字段）。

(3)如何避免 On-Disk Temporary Tables

下面是官方说明：

 The best solution is to avoid using the BLOB and TEXT types unless you really need them.
  If you can't avoid them, you may be able to use the ORDER BY SUBSTRRING(colum,length) trick to convert the values to character strings. wihich will permit in-memory temporary tables. 
  Just be sure that you are using a short engough substring that the temporary table doesn't grow larger than max_heap_table_size or tmp_table_size, or MySQL will convert the table to an on-disk MyISAM table. 
  If the Extra column of EXPLAIN contains "Using temporary",the query uses an implicit temporary table. 
  --------------下面是中文翻译
  最好的解决方案是避免使用BLOB和文本类型,除非你真的需要他们。如果无法避免它们,您可以使用ORDER BY SUBSTRRING(colum,length)将值转换为字符串。将允许使用内存临时表。
  只是确保你使用的是短engough临时表的子串，不用增长到超过max_heap_table_size tmp_table_size的大小，否则会创建一个磁盘MyISAM表
  如果解释的额外的列包含“使用临时”,查询使用隐式临时表。

六、BLOB和TEXT导致的内部磁盘临时表说明

1、因为 Memory 存储引擎不支持 BLOB和TEXT 类型，所以包含有 BLOB和TEXT 类型字段的查询，当它需要用到隐式临时表的时候，就不得不使用 on-disk的MyISAM临时表，即使它的查询结果可能只有很简单的几行数据。

这会导致一个严重的性能瓶颈，即使您能配置将MySQL的临时表存储到RAM disk上,依然还是会需要用到许多昂贵的操作系统的调用函数。在实用中还发现，某些SQL语句的临时表甚至根本连RAM disk都不能使用（此时SQL查询命令会因为不能创建临时表而失败）。

2、BLOB和TEXT这两个数据类型。这两个数据类型都用来存储大容量的数据。前者是采用二进制的形式来保存，而后者是采用字符形式来保存。

这两个数据类型与其他数据类型有本质的不同。在MYSQL数据库中，是将这两个数据类型当做有实体的对象来处理。存储引擎也会采用特别的方式来保存他们。BLOB数据类型是采用二进制的方式来存储数据。而采用二进制来存储数据时，系统没有字符集的要求，也不会设置排序规则。相反，TEXT采用字符形式来存储数据，为此有字符集和排序规则的限制。

3、因为这两种数据类型的容量比较大，为此对对这些类型的字段进行操作时，临时表就会一下子变得很大。

此时就很容易超过上面两个参数的限制。系统就会将内存临时表转换为磁盘临时表。为此这两种数据类型会增加产生磁盘临时表的几率。

4、不同的存储类型对于数据类型的支持力度是不同的。

如果某种存储类型不支持某些数据类型，那么系统就会直接采用磁盘临时表，即使数据没有超过其规定的大小。

简单的说，就是对于存储引擎，如果其不支持某些数据类型，那么对这些数据类型进行操作时，系统只能够使用磁盘临时表，而不能够使用磁盘临时表。如对于Memory存储引擎来说，其不支持BLOB和TEXT数据类型。在系统运行中，如果使用了BLOB和TEXT列，并且需要隐式临时表时，查询将不会使用内存临时表，而直接采用磁盘临时表。即使两个数据类型中的列存储的数据不多，也是如此。显然这会大大的降低数据库的性能。

七、小结

【小结】

1、如果事物超过tmptablesize 会使用磁盘临时表，没操作则用内存临时表。
2、如果使用了BLOB和TEXT列，“并且需要隐式临时表时”，直接用磁盘临时表，不会用到内存。即使没有超过maxheaptable_size的限制<他们的类型决定的>，（varchar,char 都会用内存临时表）。
3、用explain查看，其实你可以在每次执行前用 explain 分析下，要是让你使用临时表会在extra里面现实出来的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31324175/viewspace-2121067/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31324175/viewspace-2121067/