事后測(cè)試了一下，一下方法就是垃圾，看看可以，別跟著學(xué)！！！

數(shù)據(jù)庫(kù)重啟后，問(wèn)題依然暴露出來(lái)了，參數(shù)什么的都是扯，擦

記錄一個(gè)困擾我好幾天的問(wèn)題。先貼上報(bào)錯(cuò)：

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在進(jìn)行表空間遷移時(shí)，在import tablespace時(shí)，總是到固定的一張表時(shí)，出現(xiàn)連接失敗報(bào)錯(cuò)。

一開(kāi)始以為是連接超時(shí)問(wèn)題，調(diào)整超時(shí)參數(shù)后，發(fā)現(xiàn)問(wèn)題依然存在。

查看錯(cuò)誤日志，發(fā)現(xiàn)如上的報(bào)錯(cuò)信息。

這個(gè)報(bào)錯(cuò)信息很奇怪，超出了表空間限制，讓我檢查ibdata相關(guān)參數(shù)。配置文件中和ibdata相關(guān)的就innodb_data_file_path= ibdata1:256M:autoextend，調(diào)整該參數(shù)為一個(gè)較大的值。

重新執(zhí)行，錯(cuò)誤依然存在。

百度了很久，沒(méi)有一個(gè)能給出正確解決的。硬著頭皮從國(guó)外的網(wǎng)站進(jìn)行搜索，擦，竟然找到了。

說(shuō)是一個(gè)MySQL5.7的bug，需要關(guān)閉持久化統(tǒng)計(jì)信息參數(shù)(innodb_stats_persistent=OFF)，才能解決。

感覺(jué)重建光明啊。

修改后，報(bào)錯(cuò)真的解決了。

不知道是使用中文的小朋友沒(méi)有遇到過(guò)這個(gè)問(wèn)題 還是百度略拙，趕緊記錄一下，額哈哈。

注意：

持久化統(tǒng)計(jì)信息參數(shù)是在數(shù)據(jù)庫(kù)關(guān)閉時(shí)，將表的統(tǒng)計(jì)信息存儲(chǔ)到本地，在打開(kāi)數(shù)據(jù)庫(kù)時(shí)，這些統(tǒng)計(jì)信息還會(huì)保留關(guān)閉前的樣子。這樣在需要生成SQL執(zhí)行計(jì)劃時(shí)，不需要現(xiàn)收集統(tǒng)計(jì)信息，它就在哪了。

這個(gè)參數(shù)優(yōu)化了剛啟動(dòng)數(shù)據(jù)庫(kù)的SQL解析效率。關(guān)閉后，這一效率就沒(méi)有了，作為補(bǔ)丁，可以手動(dòng)寫個(gè)腳本，在啟動(dòng)數(shù)據(jù)庫(kù)后，自動(dòng)進(jìn)行統(tǒng)計(jì)更新。

總結(jié)

以上是生活随笔為你收集整理的mysql表空间界限_MySQL5.7 import表结构报错超出表空间界限的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。