使用。在Debian 9上使用MySQL 5.6，总的数据库大小约为450Gb。
更新到5.7，运行mysql_upgrade，发现已经占用了150GB左右。有2张表真的很大，它们在'复制到tmp表'中停留了几个小时。
注意到 innodb_file_per_table 开启，并创建了以前没有的大型ibd文件。
从快照恢复，禁用file_per_table，再次运行mysql_upgrade。100GB没了，这几乎是我总DB的14。
在第一种情况下，它从ibdata中提取数据，并将其放入一个单独的文件中，但ibdata从不收缩，所以所占空间几乎增加了一倍。
在第二种情况下会发生什么？是否在ibdata文件中创建了一个临时表，而这个表永远不会收缩，所以即使表不再使用时，空间也会消失？
我注意到的另一件事是，空间的消耗要等到查询在复制到临时表的状态下一个小时左右才会开始。
1) 有什么方法可以避免空间增加？
是否可以在打开file_per_table的情况下运行update，然后禁用它，再运行files_per_table。alter table engine innodb 腾出空间？
2）有什么方法可以预测会占用多少空间？至少每张表
3) max_tmp_table_size是如何发挥作用的？
听起来你把自己画进了一个角落，因为你没有从一开始就运行innodb_file_per_table，所以现在你有一个巨大的，不可收缩的ibdata1文件。
1) 没有。
1.1）通过在ibdata1文件外重建表，然后再重建到ibdata1内，重新使用ibdata1内的一些未使用的空间，可能会减少整体空间的使用。
2）是的。
SELECT TABLE_SCHEMA, TABLE_NAME, DATA_LENGTH, INDEX_LENGTH FROM information_schema.TABLES;
3）没有。你所看到的表可能是由于某种原因而被重建的表（不知道为什么，我承认我没有看到过这种情况发生，从 mysql_upgrade max_tmp_table_size只适用于隐式查询（当查询计划中写着 using temporary)和显性(CREATE TEMPORARY TABLE ...)临时表，不用于表的重建。
唯一（？）的方法是切换到 file_per_table 没有磁盘膨胀是