升級UCenter 1.7,提示錯誤1031

湖中沉

myawei 發表于 2023-5-22 18:48
測試了一下HeidiSQL，還不太熟悉，導出的數據表結構如下。

你對比下navicat導出，會發現有所不同

jjii33

這樣是看不出來的,要看錯誤提示

myawei

湖中沉 發表于 2023-5-22 19:45
你對比下navicat導出，會發現有所不同

謝謝老兄，認真對比后發現確實有所不同，主要在下面兩句，摘出來請指教是哪里的問題呢。

phpmyadmin備份的數據表：

1. 1.  `username` char(15) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
   
2. 2.ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

復制代碼

navicat備份的數據表：

1. 1.  `username` char(15) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
   
2. 2. ENGINE = InnoDB AUTO_INCREMENT = 2 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;

復制代碼

湖中沉

myawei 發表于 2023-5-23 12:33
謝謝老兄，認真對比后發現確實有所不同，主要在下面兩句，摘出來請指教是哪里的問題呢。

phpmyadmin備份 ...

關鍵就是ROW_FORMAT這個，是多余的，他會導致每個重新導入的數據表的ROW_FORMAT被強制設定而非默認值，這樣在其他程序操作的時候，就會出錯。
除了navicat，其他見過的數據庫操作軟件導出數據均不會帶這個ROW_FORMAT值

湖中沉

myawei 發表于 2023-5-23 12:33
謝謝老兄，認真對比后發現確實有所不同，主要在下面兩句，摘出來請指教是哪里的問題呢。

phpmyadmin備份 ...

另外，一般正常導出，帶上CHARSET=xxx就可以了，navicat不知道出于什么考慮，導出的是CHARACTER SET = xxx

myawei

湖中沉 發表于 2023-5-23 12:58
關鍵就是ROW_FORMAT這個，是多余的，他會導致每個重新導入的數據表的ROW_FORMAT被強制設定而非默認值，這 ...

原來是這里的問題，我原來猜想的是phpmyadmin是DEFAULT CHARSET=utf8mb4，而navicat的是CHARACTER SET = utf8mb4，它沒有DEFAULT，原來是ROW_FORMAT = Dynamic，看數據表，確實Dynamic和InnoDB好像關聯緊密。又多了幾分了解，非常感謝！

myawei

湖中沉 發表于 2023-5-23 13:01
另外，一般正常導出，帶上CHARSET=xxx就可以了，navicat不知道出于什么考慮，導出的是CHARACTER SET = xx ...

也是很奇怪，翻看了下之前3.2版本用navicat備份的數據，里面也是有ROW_FORMAT，但是恢復很正常。莫非是MyISAM換成InnoDB，ROW_FORMAT這個就不能用了？

1. ENGINE = MyISAM AUTO_INCREMENT = 1 CHARACTER SET = gbk COLLATE = gbk_chinese_ci ROW_FORMAT = Dynamic;

復制代碼

1. ENGINE = MyISAM AUTO_INCREMENT = 2 CHARACTER SET = gbk COLLATE = gbk_chinese_ci ROW_FORMAT = Fixed;

復制代碼

湖中沉

myawei 發表于 2023-5-23 13:53
也是很奇怪，翻看了下之前3.2版本用navicat備份的數據，里面也是有ROW_FORMAT，但是恢復很正常。莫非是M ...

變更數據庫引擎對ROW_FORMAT是有要求的，所以這問題只在3.5的升級上出現問題，其他版本升級或者備份恢復是無關的

myawei

湖中沉 發表于 2023-5-23 14:54
變更數據庫引擎對ROW_FORMAT是有要求的，所以這問題只在3.5的升級上出現問題，其他版本升級或者備份恢復 ...

明白啦，謝謝呀??！

jjii33

學習了,我的反復測試,沒有出現問題~