事后测试了一下，一下方法就是垃圾，看看可以，别跟着学！！！

数据库重启后，问题依然暴露出来了，参数什么的都是扯，擦

记录一个困扰我好几天的问题。先贴上报错：

space name jxtms/CostManage, which is outside the tablespace bounds. B

yte offset 0, len 16384, i/o type read. If you get this error at mysqld startup, please check that your my.cnf matches the ibdata files that you have in the MySQL server.

MySQL5.7在进行表空间迁移时，在import tablespace时，总是到固定的一张表时，出现连接失败报错。

一开始以为是连接超时问题，调整超时参数后，发现问题依然存在。

查看错误日志，发现如上的报错信息。

这个报错信息很奇怪，超出了表空间限制，让我检查ibdata相关参数。配置文件中和ibdata相关的就innodb_data_file_path= ibdata1:256M:autoextend，调整该参数为一个较大的值。

重新执行，错误依然存在。

百度了很久，没有一个能给出正确解决的。硬着头皮从国外的网站进行搜索，擦，竟然找到了。

说是一个MySQL5.7的bug，需要关闭持久化统计信息参数(innodb_stats_persistent=OFF)，才能解决。

感觉重建光明啊。

修改后，报错真的解决了。

不知道是使用中文的小朋友没有遇到过这个问题 还是百度略拙，赶紧记录一下，额哈哈。

注意：

持久化统计信息参数是在数据库关闭时，将表的统计信息存储到本地，在打开数据库时，这些统计信息还会保留关闭前的样子。这样在需要生成SQL执行计划时，不需要现收集统计信息，它就在哪了。

这个参数优化了刚启动数据库的SQL解析效率。关闭后，这一效率就没有了，作为补丁，可以手动写个脚本，在启动数据库后，自动进行统计更新。