MySQL 5.6 整理表的碎片

https://blog.51cto.com/dadaman/1957229

可以看到，当前表的碎片率超高了，50.6%。

有三种办法整理碎片

这三种 *** 作都是先创建一个临时表复制完成后再删除旧表，所以在执行 *** 作的过程中磁盘会先增大。

会锁表

https://dev.mysql.com/doc/refman/5.6/en/

https://dev.mysql.com/doc/refman/5.6/en/optimize-table.html

会锁表

pt-online-schema-change - ALTER tables 无需锁表。

整理结果很明显，整理后碎片率0.3%。

这里有几个参数需要介绍一下：

--dry-run

这个参数不建立触发器，不拷贝数据，也不会替换原表。只是创建和更改新表。

--execute

表明你已经阅读了文档，并且确认要 alter the table。你必须配置这个参数来 alter the table。如果你不配置，那么工具将只进行一些安全检查然后就退出了。这帮助确保你已经阅读了文档，并且了解如何使用该工具。如果你没有阅读这些文档，那么不会设置该参数。

--critical-load

每次chunk *** 作前后，会根据show global status统计指定的状态量的变化，默认是统计Thread_running。目的是为了安全，防止原始表上的触发器引起负载过高。这也是为了防止在线DDL对线上的影响。超过设置的阀值，就会终止 *** 作，在线DDL就会中断。提示的异常如上报错信息。

--max-lag

type: timedefault: 1s

lag 滞后偏移

暂停数据拷贝，直到所有replicas的lag值低于该值。在每个 data-copy query (each chunk)后，工具会通过Seconds_Behind_Master查询所有replica的 replication lag 。如果任何replica lag大于该值，那么工具会sleep --check-interval 秒，然后再次检查所有replica。如果你指定 --check-slave-lag ，那么工具会检查那台server，而不是所有server。如果你想控制哪个提供工具的监控，配置DSN值 --recursion-method 。

工具会等待直到replicas停止lagging。如果任一replica停止，工具会一直处于等待状态直到该replica启动。 在所有replicas运行并且lagging不大的情况下，数据拷贝继续。

工具在等待的时候，会打印进程报告。如果replica停止了，会立即打印进程报告，然后在每个进程报告期间重复。

--check-interval

type: timedefault: 1

Sleep time between checks for --max-lag .

--max-load

选项定义一个阀值，在每次chunk *** 作后，查看show global status状态值是否高于指定的阀值。该参数接受一个mysql status状态变量以及一个阀值，如果没有给定阀值，则定义一个阀值为为高于当前值的20%。注意这个参数不会像--critical-load终止 *** 作，而只是暂停 *** 作。当status值低于阀值时，则继续往下 *** 作。是暂停还是终止 *** 作这是--max-load和--critical-load的差别。

--charset

简写: -Atype: string

设置默认字符集。如果值为 utf8，设置 Perl’s binmode on STDOUT to utf8，传送 mysql_enable_utf8 参数到 DBD::mysql，然后在连接到MySQL后运行 SET NAMES UTF8 。其他的值也是在STDOUT设置 binmode，然后在连到MySQL后运行 SET NAMES 。

--check-replication-filters

检查复制中是否设置了过滤条件，如果设置了，程序将退出

--nocheck-replication-filters

不检查复制中是否设置了过滤条件

--set-vars

设置mysql的变量值

--check-slave-lag

检查主从延迟

--no-version-check

不检查版本，在阿里云服务器中一般加入此参数，否则会报错

本文内容来源于对客户的三个问题的思考：

以下测试都是在 MySQL 8.0.21 版本中完成，不同版本可能存在差异，可自行测试；

临时表和临时文件都是用于临时存放数据集的地方；

一般情况下，需要临时存放在临时表或临时文件中的数据集应该符合以下特点：

从临时表|临时文件产生的主观性来看，分为2类：

用户创建临时表：

  -- 用户创建临时表(只有创建临时表的会话才能查看其创建的临时表的内容)

  注意：

  可以创建和普通表同名临时表，其他会话可以看到普通表(因为看不到其他会话创建的临时表)；

  创建临时表的会话会优先看到临时表；

  -- 同名表的创建的语句如下

  当存在同名的临时表时，会话都是优先处理临时表(而不是普通表)，包括：select、update、delete、drop、alter 等 *** 作；

查看用户创建的临时表：

  任何 session 都可以执行下面的语句；

  查看用户创建的当前 active 的临时表(不提供 optimizer 使用的内部 InnoDB 临时表信息)

  注意

  用户创建的临时表，表名为t1，

  但是通过 INNODB_TEMP_TABLE_INFO 查看到的临时表的 NAME 是#sql开头的名字，例如：#sql45aa_7c69_2 ；

  另外 information_schema.tables 表中是不会记录临时表的信息的。

用户创建的临时表的回收：

用户创建的临时表的其他信息&参数：

  会话临时表空间存储 用户创建的临时表和优化器 optimizer 创建的内部临时表(当磁盘内部临时表的存储引擎为 InnoDB 时)；

  innodb_temp_tablespaces_dir 变量定义了创建 会话临时表空间的位置，默认是数据目录下的#innodb_temp 目录；

  文件类似temp_[1-20].ibt ；

  查看会话临时表空间的元数据：

  用户创建的临时表删除后，其占用的空间会被释放(temp_[1-20].ibt文件会变小)。

  在 MySQL 8.0.16 之前，internal_tmp_disk_storage_engine 变量定义了用户创建的临时表和 optimizer 创建的内部临时表的引擎，可选 INNODB 和 MYISAM ；

  从 MySQL 8.0.16 开始，internal_tmp_disk_storage_engine参数被移除，默认使用InnoDB存储引擎；

  innodb_temp_data_file_path 定义了用户创建的临时表使用的回滚段的存储文件的相对路径、名字、大小和属性，该文件是全局临时表空间(ibtmp1)；

  可以使用语句查询全局临时表空间的数据文件大小：

SQL 什么时候产生临时表|临时文件呢？

  需要用到临时表或临时文件的时候，optimizer 自然会创建使用(感觉是废话，但是又觉得有道理=.=!)；

  (想象能力强的，可以牢记上面这句话；想象能力弱的，只能死记下面的 SQL 了。我也弱，此处有个疲惫的微笑