Schema mismatch一种处理办法

[TSOTOF]

Schema mismatch的问题我试了几种方法都不太行，后来猜测是tosql生成的建表sql代码有问题，于是我找来了原始的CREATE TABLE语句，用原始的CREATE TABLE语句建表。

建表之后再load_data(我没有试过，因为担心导出的sdi文件会和原始的CREATE TABLE不匹配)，或者直接手动操作： 1.删除原tablespace 2.复制ibd文件 3.重新建立tablespace 这样处理就不会出现scheme mismatch的问题啦！

事后来看这件事情，上面的操作说明scheme mismatch的一种情况是出在表结构上的，有可能.ibd文件没有包含原始table的全部表结构信息，或者存在歧义。那么当没有原始的CREATE TABLE语句时，能否仅调整tosql的结果，也就是.sql文件来达到目的呢？我后面只尝试了一次，确实也解决了scheme mismatch的问题：

我比较了原始CREATE TABLE语句和.sql中语句的差别，发现主要的区别出现在CREATE TABLE的末尾，一般是定义主键和索引的语句上。我把tosql生成的.sql文件中定义INDEX的语句改成定义KEY：

KEY `F_PRT_ENDDATE` (`F_PRT_ENDDATE`),
KEY `S_INFO_WINDCODE` (`S_INFO_WINDCODE`) USING BTREE,
KEY `S_INFO_STOCKWINDCODE` (`S_INFO_STOCKWINDCODE`) USING BTREE

用新的CREATE TABLE语句建立表格，没有出现Scheme mismatch的问题。

当然我遇到的情况仅仅是其中一种，具体怎么更改.sql中的CREATE TABLE语句还需要遇到具体问题再尝试，只是大家在碰到定义INDEX或者定义KEY的语句时或许可以试着改成相反的，或许能有帮助。

[zerommc]

我同样遇到 'Schema mismatch (Clustered index validation failed. Because the .cfg file is missing, table definition of the IBD file could be different. Or the data file itself is already corrupted.)') 这个问题，也试着用修改key 的方式，依然是这个错误。 比对ibd 结构，发现要还原的ibd文件 se_private_data 属性有多了一个default_null=1 子属性。大概率是因为这个属性导致结果不一致。但这个貌似无法通过修改字段熟悉来解决。