MySQL 5.7怎么爬出临时表空间的坑

导读

如何确认临时表是由哪个线程创建的?

上次我们介绍了MySQL 5.7临时表空间特性及使用注意事项,这次我们来介绍如何确认是哪个线程创建的临时表,以及如何释放临时表。

首先,我们查看当前的线程ID

yejr@imysql.com [test]>SELECT CONNECTION_ID();
+-----------------+
| CONNECTION_ID() |
+-----------------+
|            2470 |
+-----------------+

在当前会话中创建临时表

yejr@imysql.com [test]>create temporary table tmp1 select * from information_schema.global_status;

立即查看临时表信息

yejr@imysql.com [test]>select * from information_schema.innodb_temp_table_info;
+----------+-----------------------+--------+-------+----------------------+---------------+
| TABLE_ID | NAME                  | N_COLS | SPACE | PER_TABLE_TABLESPACE | IS_COMPRESSED |
+----------+-----------------------+--------+-------+----------------------+---------------+
|      505 | #sql17ab5_4000003a6_4 |      5 |   512 | FALSE                | FALSE         |
+----------+-----------------------+--------+-------+----------------------+---------------+

我们观察到 NAME 列的值是 #sql17ab5_4000003a6_4,它由3部分构成:

  1. 第1部分,由“#sql”字符串开始,并加上随机值;
  2. 第2部分,一串”疑似”16进制字符;
  3. 第3部分,单调递增的数值;

第2部分,我们注意到是“疑似”16进制,我们把“3a6“从16进制转成10进制试试看:

yejr@imysql.com [test]>select conv('9a6', 16, 10);
+---------------------+
| conv('9a6', 16, 10) |
+---------------------+
| 2470                |
+---------------------+

可以看到,正好和当前的线程ID是一样的,这证实了我们的设想。

我手上有两个MySQL 5.7版本,下面是多次、不定时创建临时表的整个观察过程记录。
首先是Linux系统下的5.7.18版本:

Server version:    5.7.18-log MySQL Community Server (GPL)

yejr@imysql.com[test]> select connection_id();
+-----------------+
| connection_id() |
+-----------------+
|            1737 |
+-----------------+

yejr@imysql.com[test]> select conv(1737, 10 ,16);
+--------------------+
| conv(1737, 10 ,16) |
+--------------------+
| 6C9                |
+--------------------+

yejr@imysql.com[test]> select * from information_schema.innodb_temp_table_info where NAME like ‘%6C9%’;;
+----------+----------------+--------+-------+----------------------+---------------+
| TABLE_ID | NAME           | N_COLS | SPACE | PER_TABLE_TABLESPACE | IS_COMPRESSED |
+----------+----------------+--------+-------+----------------------+---------------+
|      121 | #sql7e95_6c9_5 |      5 |   190 | FALSE                | FALSE         |
|      120 | #sql7e95_6c9_4 |      5 |   190 | FALSE                | FALSE         |
|      119 | #sql7e95_6c9_3 |      5 |   190 | FALSE                | FALSE         |
|      118 | #sql7e95_6c9_2 |      5 |   190 | FALSE                | FALSE         |
+----------+----------------+--------+-------+----------------------+---------------+

以及Mac系统下的MySQL 5.7.16版本:

Server version:    5.7.16-log MySQL Community Server (GPL)


yejr@imysql.com[test]> select connection_id();
+-----------------+
| connection_id() |
+-----------------+
|            934  |
+-----------------+

yejr@imysql.com[test]> select conv(934, 10 ,16);
+--------------------+
| conv(1737, 10 ,16) |
+--------------------+
| 3A6                |
+--------------------+

yejr@imysql.com[test]> select * from information_schema.innodb_temp_table_info where NAME like ‘%3A6%’;;
+----------+-------------------------+--------+-------+----------------------+---------------+
| TABLE_ID | NAME                    | N_COLS | SPACE | PER_TABLE_TABLESPACE | IS_COMPRESSED |
+----------+-------------------------+--------+-------+----------------------+---------------+
|      518 | #sql17ab5_31000003a6_31 |      5 |   512 | FALSE                | FALSE         |
|      517 | #sql17ab5_29000003a6_29 |     20 |   512 | FALSE                | FALSE         |
|      516 | #sql17ab5_26000003a6_26 |      5 |   512 | FALSE                | FALSE         |
|      515 | #sql17ab5_23000003a6_23 |      5 |   512 | FALSE                | FALSE         |
|      514 | #sql17ab5_1e000003a6_1e |      5 |   512 | FALSE                | FALSE         |
|      513 | #sql17ab5_1b000003a6_1b |      5 |   512 | FALSE                | FALSE         |
|      512 | #sql17ab5_18000003a6_18 |      5 |   512 | FALSE                | FALSE         |
|      511 | #sql17ab5_16000003a6_16 |      5 |   512 | FALSE                | FALSE         |
|      510 | #sql17ab5_14000003a6_14 |      5 |   512 | FALSE                | FALSE         |
|      509 | #sql17ab5_12000003a6_12 |      5 |   512 | FALSE                | FALSE         |
|      508 | #sql17ab5_10000003a6_10 |      5 |   512 | FALSE                | FALSE         |
|      507 | #sql17ab5_d000003a6_d   |      5 |   512 | FALSE                | FALSE         |
|      506 | #sql17ab5_a000003a6_a   |      5 |   512 | FALSE                | FALSE         |
|      505 | #sql17ab5_4000003a6_4   |      5 |   512 | FALSE                | FALSE         |
+----------+-------------------------+--------+-------+----------------------+---------------+

从这个结果能看到临时表的 NAME 的第三部分数值在两个版本中的表现不一样。

• 在5.7.16版本上,虽然也是单调递增,但并不是顺序的,而是有跳跃,跳跃规则未知;
• 在5.7.18版本上,在保持单调递增的基础上,每次值都是顺序增长的,未跳跃。

好了,现在我们知道只要根据当前的线程ID,就能找到该线程ID里所创建的临时表,想要释放这些临时表,只需要查询 I_S.INNODB_TEMP_TABLE_INFO 表的 NAME 列值所有包含当前线程ID的记录,杀掉对应的线程ID即可。

参考

MySQL 5.7临时表空间怎么玩才能不掉坑里

导读

MySQL 5.7起支持独立临时表空间,但个别时候也可能会踩坑的。

MySQL 5.7起,开始采用独立的临时表空间(和独立的undo表空间不是一回事哟),命名ibtmp1文件,初始化12M,且默认无上限。

选项 innodb_temp_data_file_path 可配置临时表空间相关参数。

innodb_temp_data_file_path = ibtmp1:12M:autoextend

临时表空间的几点说明

• 临时表空间不像普通InnoDB表空间那样,不支持裸设备(raw device)。
• 临时表空间使用动态的表空间ID,因此每次重启时都会变化(每次重启时,都会重新初始化临时表空间文件)。
• 当选项设置错误或其他原因(权限不足等原因)无法创建临时表空间时,mysqld实例也无法启动。
• 临时表空间中存储这非压缩的InnoDB临时表,如果是压缩的InnoDB临时表,则需要单独存储在各自的表空间文件中,文件存放在 tmpdir(/tmp)目录下。
• 临时表元数据存储在 INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO 视图中。

有时执行SQL请求时会产生临时表,极端情况下,可能导致临时表空间文件暴涨,帮人处理过的案例中最高涨到快300G,比以前遇到的 ibdata1 文件暴涨还要猛…

临时表使用的几点建议

• 设置 innodb_temp_data_file_path 选项,设定文件最大上限,超过上限时,需要生成临时表的SQL无法被执行(一般这种SQL效率也比较低,可借此机会进行优化)。
• 检查 information_schema.INNODB_TEMP_TABLE_INFO,找到最大的临时表对应的线程,kill之即可释放,但 ibtmp1 文件则不能释放(除非重启)。
• 择机重启实例,释放 ibtmp1 文件,和 ibdata1 不同,ibtmp1 重启时会被重新初始化而 ibdata1 则不可以。
• 定期检查运行时长超过N秒(比如N=300)的SQL,考虑干掉,避免垃圾SQL长时间运行影响业务。

附:临时表测试案例

原表DDL

CREATE TEMPORARY TABLE `tmp1` (
  `id` int(10) unsigned NOT NULL DEFAULT '0',
  `name` varchar(50) NOT NULL DEFAULT '',
  `aid` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `nid` int(11) unsigned GENERATED ALWAYS AS ((`id` + 1)) VIRTUAL NOT NULL,
  `nnid` int(11) unsigned GENERATED ALWAYS AS ((`id` + 1)) STORED NOT NULL,
  PRIMARY KEY (`aid`),
  KEY `name` (`name`),
  KEY `id` (`id`),
  KEY `nid` (`nid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

原表大小只有 120MB,从这个表直接 INSERT…SELECT 导数据到tmp1表。

-rw-r-----  1 yejr  imysql   120M Apr 14 10:52 /data/mysql/test/sid.ibd

生成临时表(去掉虚拟列,临时表不支持虚拟列,然后写入数据),还更大了(我也不解,以后有机会再追查原因)。

-rw-r-----  1 yejr  imysql   140M Jun 25 09:55 /Users/yejinrong/mydata/ibtmp1

查看临时表元数据信息

yejr@imysql.com [test]>select * from 
 INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO\G
*********************** 1. row ***********************
            TABLE_ID: 405
                NAME: #sql14032_300000005_3
              N_COLS: 6
               SPACE: 421
PER_TABLE_TABLESPACE: FALSE
       IS_COMPRESSED: FALSE

再删除索引,结果,又更大了

-rw-r-----  1 yejr  imysql   204M Jun 25 09:57 /data/mysql/ibtmp1

第二次测试删除索引后,变成了200M(因为第二次测试时,我设置了临时表最大200M)

innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:200M


-rw-r-----  1 yejr  imysql   200M Jun 25 10:15 /data/mysql/ibtmp1

执行一个会产生临时表的慢SQL

注:MySQL 5.7起,执行UNION ALL不再产生临时表(除非需要额外排序)。

yejr@imysql.com [test]>explain select * from tmp1 union 
  select id,name,aid from sid\G
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: tmp1
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 3986232
     filtered: 100.00
        Extra: NULL
*************************** 2. row ***************************
           id: 2
  select_type: UNION
        table: sid
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 802682
     filtered: 100.00
        Extra: NULL
*************************** 3. row ***************************
           id: NULL
  select_type: UNION RESULT
        table: <union1,2>
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: NULL
     filtered: NULL
        Extra: Using temporary

文件涨到588M还没结束,我直接给卡了

-rw-r-----  1 yejr  imysql   588M Jun 25 10:07 /data/mysql/ibtmp1

第二次测试时,设置了临时表空间文件最大200M,再执行会报错:

yejr@imysql.com [test]>select * from tmp1 union 
 select id,name,aid from sid;
ERROR 1114 (HY000): The table '/var/folders/bv/j4tjn6k54dj5jh1tl8yn6_y00000gn/T/#sql14032_5_8' is full

参考

MySQL 5.7版本新特性连载(六)

本文是基于MySQL-5.7.7-rc版本,未来可能 还会发生更多变化。

  1. 自动判断底层I/O设备是否可以支持原子IO(AIO),检测到的话,会自动关闭 double write buffer,进一步提升性能。
  2. 支持 innodb_page_cleaners 选项可设置多个page cleaner线程提高脏页刷新效率。
  3. 可通过设置 innodb_undo_log_truncate 等选项自动删除不用的 undo log。
  4. 加强InnoDB read-only模式的性能。
  5. 支持一个表上有多个触发器,这样一来,原先已有触发器表也可以支持用 pt-osc 了。
  6. 新增 log_syslog 选项,可将MySQL日志打印到系统日志文件中。
  7. InnoDB和MyISAM引擎的分区表也支持ICP特性。
  8. 支持对在线某个连接直接查看执行计划,比如 EXPLAIN FOR CONNECTION 1024
  9. 支持在线(INPLACE)增加 VARCHAR 列的长度。不过 0-255 长度是一个区间,256 以上是另一个区间,不能跨越255这个坎,比如把长度从 100 扩展成 1000(因为 255 长度以内额外用1个字节表示,大于 255 长度则需要额外2个字节表示)。另外还不支持在线缩小 VARCHAR 的长度。
  10. 以及更多关于性能上的改善提升,包括客户端连接效率提升批量数据加载效率提升sort buffer中存储的非排序字段是压缩模式的(提高内存利用率)、UNION ALL不再产生临时表解析器重构、查询优化器进一步完善(比如增加可控CBO规则)等等。

 

延伸阅读:

整理的比较仓促,若有遗漏或失误,请留言回复。MySQL 5.7新版本特性至此连载 结束,谢谢大家的关注!

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠

 

MySQL 5.7版本新特性连载(五)

本文是基于MySQL-5.7.7-rc版本,未来可能 还会发生更多变化。

1、支持多源复制(Multi-source replication),这对采用分库分表的同学绝对是个超级重磅福音。可以把多个MASTER的数据归并到一个实例上, 有助于提高SLAVE服务器的利用率。不过如果是同一个表的话,会存在主键和唯一索引冲突的风险,需要提前做好规划。

【新特性实践】
MySQL 5.7的多源复制采用多通道的模式,例如用以下方法可以创建多个复制通道,将多个MASTER上的数据复制到同一个SLAVE节点中去:

-- 需要先把 MASTER_INFO_REPOSITORY 和 RELAY_LOG_INFO_REPOSITORY 改成 TABLE 模式
[yejr@imysql.com]> SET GLOBAL MASTER_INFO_REPOSITORY = "TABLE";
Query OK, 0 rows affected (0.00 sec)

[yejr@imysql.com]> SET GLOBAL RELAY_LOG_INFO_REPOSITORY = "TABLE";
Query OK, 0 rows affected (0.00 sec)

-- 创建第一个复制通道
[yejr@imysql.com]> CHANGE MASTER TO MASTER_HOST='1.2.3.4', MASTER_USER='user', MASTER_PASSWORD='repl' FOR CHANNEL 'MASTER-01';
Query OK, 0 rows affected, 2 warnings (0.00 sec)

-- 创建第二个复制通道
[yejr@imysql.com]> CHANGE MASTER TO MASTER_HOST='2.3.4.5', MASTER_USER='user', MASTER_PASSWORD='repl' FOR CHANNEL 'MASTER-02';
Query OK, 0 rows affected, 2 warnings (0.00 sec)

-- 查看第二个复制通道的状态
[yejr@imysql.com]> SHOW SLAVE STATUS FOR CHANNEL 'MASTER-02';
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 2.3.4.5
                  Master_User: user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: 
          Read_Master_Log_Pos: 4
               Relay_Log_File: yejr-relay-bin-master@002d02.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: 
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 0
              Relay_Log_Space: 154
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 0
                  Master_UUID: 
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: 
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: f0df162a-1a39-11e5-883a-782bcb65f419:1-11025782
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: master-02
1 row in set (0.00 sec)

其他和复制相关的SQL指令和以往也基本一样,只需在加上 FOR CHANNEL ‘CHANNEL-NAME’ 子句即可。

此外,还支持在线修改replication filter规则,不过不是太建议使用filter规则,因此不重点介绍了。执行下面的SQL命令可以完成filter规则修改:

[yejr@imysql.com]> CHANGE REPLICATION FILTER
 REPLICATE_DO_DB = (d1), REPLICATE_IGNORE_DB = (d2);

 

2、支持多线程复制(Multi-Threaded Slaves, 简称MTS),在5.6版本中实现了SCHEMA级别的并行复制,不过意义不大,因为我们线上大部分实例的读写压力基本集中在某几个数据表,基本无助于缓解复制延迟问题。倒是MariaDB的多线程并行复制大放异彩,有不少人因为这个特性选择MariaDB(比如我也是其一,呵呵)。

MySQL 5.7 MTS支持两种模式,一种是和5.6一样,另一种则是基于binlog group commit实现的多线程复制,也就是MASTER上同时提交的binlog在SLAVE端也可以同时被apply,实现并行复制。关于MTS的更多详细介绍可以查看姜承尧的分享 MySQL 5.7 并行复制实现原理与调优,我这里就不重复说了。

值得一提的是,经过对比测试,5.7采用新的并行复制后,仍然会存在一定程度的延迟,只不过相比5.6版本减少了86%,相比MariaDB的并行复制延迟也小不少

 

下一期,我们继续讲讲5.7的其他新特性。

延伸阅读:

整理的比较仓促,若有遗漏或失误,请留言回复,谢谢!

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠

 

MySQL 5.7版本新特性连载(三)

本文是基于MySQL-5.7.7-rc版本,未来可能 还会发生更多变化。本节开始讲5.7版本中的新特性。

1、安全性
a. 用户表 mysql.user 的 plugin字段不允许为空, 默认值是 mysql_native_password,而不是 mysql_old_password,不再支持旧密码格式;
b. 增加密码过期机制,过期后需要修改密码,否则可能会被禁用,或者进入沙箱模式;
c. 使用 mysql_install_db 初始化时,默认会自动生成随机密码,并且不创建除 root@localhost 外的其他账号,也不创建 test 库;

【新特性实践】

执行 mysql_install_db 进行新实例初始化:

[yejr@imysql.com]# ./bin/mysql_install_db --user=mysql --datadir=/data/mysql/

2015-06-24 13:55:29 [WARNING] mysql_install_db is deprecated. Please consider switching to mysqld --initialize
2015-06-24 13:55:38 [ERROR]   Child process: /opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/bin/mysqld terminated prematurely with errno= 32
2015-06-24 13:55:38 [ERROR]   Failed to execute /opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/bin/mysqld --bootstrap --datadir=/data/mysql --lc-messages-dir=/usr/share/mysql --lc-messages=en_US
-- server log begin --
mysqld: [Warning] --bootstrap is deprecated. Please consider using --initialize instead
-- server log end --

可以看到提示 mysql_install_db 已经不再推荐使用了,建议改成 mysqld –initialize 完成实例初始化。

改成 mysqld –initialize 后,如果 datadir 指向的目标目录下已经有数据文件,则会有类似提示:

[yejr@imysql.com]#./bin/mysqld --user=mysql --basedir=/opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/ --datadir=/data/mysql --initial --initialize-insecure

2015-06-24T06:05:05.533588Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2015-06-24T06:05:05.533627Z 0 [ERROR] Aborting

因此,需要先确保 datadir 目标目录下是空的,避免误操作破坏已有数据。

另外,在初始化时如果加上 –initial-insecure,则会创建空密码的 root@localhost 账号,否则会创建带密码的 root@localhost 账号,密码直接写在 log-error 日志文件中(在5.6版本中是放在 ~/.mysql_secret 文件里,更加隐蔽,不熟悉的话可能会无所适从)

[yejr@imysql.com]#./bin/mysqld --user=mysql --basedir=/opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/ --datadir=/data/mysql --initial

2015-06-24T06:14:31.458905Z 0 [Warning] Insecure configuration for --secure-file-priv: Current value does not restrict location of generated files. Consider setting it to a valid, non-empty path.

初始化完毕后,如果没使用新版本的客户端登入,还会报告类似下面的错误:

mysql -uroot -p
Enter password:
ERROR 1862 (HY000): Your password has expired. To log in you must change it using a client that supports expired passwords.

上面的错误提示意思是需要用当前版本的客户端登入,因为新用户登入后需要立刻修改密码,否则无法继续后续的工作:

[(root@imysql.com)]>use mysql
ERROR 1820 (HY000): You must SET PASSWORD before executing this statement

[(root@imysql.com)]>set password = password('abcd');
Query OK, 0 rows affected, 1 warning (0.00 sec)

修改完密码后,就可以继续使用旧版本的客户端工具了。

下一期,我们继续讲讲5.7的其他新特性。

 

延伸阅读:

整理的比较仓促,若有遗漏或失误,请留言回复,谢谢!

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠