首先我们使用mysqldump备份了school数据库，现在我们恢复它。
mysql -uroot -p123456 school<c:/fp/school.sql
报错了，这显示是编码不一致导致的，那是因为啥呢，原来mysqldump默认的编码
–default-character-set=charset_name 设置字符集，默认utf8,而cmd相当于一个mysql客户端，现在要去请求mysql服务器，并上传一个sql文件，这个文件的编码是utf-8格式。有点类似于浏览器访问服务器的编码问题。那么mysql客户端请求mysql服务器是使用什么编码格式呢？
show variables like 'char%'
character_set_client 从客户端发送的语句默认编码格式。此变量的会话值是在客户端连接到服务器时使用客户端请求的字符集设置的。我们可以使用--default-character-set显式指定此字符集。从上面可以看到character_set_client默认使用gbk编码，所以我们使用mysql导入时候需显示指定字符集。
mysql -uroot -p123456 --default-character-set=utf8 school<c:/fp/school.sql
乱码搞定了，但是又报Row size too large(>8126),这又是因为啥呢？原因是mysql的innodb是按照page存储数据的。每个page最大存储为16K=16384字节。而每个page两行数据，所以每一行最大是8k=8192字节数据。而上面是显示Row size too large(>8126)说明最多存储8126个字节，而剩下的66个字节我猜测是存储行信息的。
而innodb默认的文件存储格式是Antelope（支持的行格式为COMPACT、REDUNDANT）
在Antelope中对于变长字段，低于768字节的，不会进行存储在溢出页，也就是说会直接存在page页，所以当有多个变长字段，那么很快就超过了8126个字节。
而Innodb还支持Barracuda文件格式（支持的行格式为DYNAMIC、COMPRESSED）这种格式对blob字段的处理方式是在page里面只存储一个20byte大小的指针，其他完全存在溢出区，所以轻易不会超过8K.
SET GLOBAL innodb_file_format = barracuda;再次执行导入，就成功了。
如果还不成功，那就在sql文件中对应的大文件表下面加上
ALTER TABLE score ROW_FORMAT=DYNAMIC;结构数据整体分离
mysqldump -uroot -p123456 -d school>c:/fp/school.sql--no-data或 -d 只导出表结构信息，不导出数据，所有表的创建语句都存到了school.sql中
mysqldump -uroot -p123456 -t school>c:/fp/school_data.sql--no-create-info, -t只导出数据，不包含表结构,所有表的数据都以insert语句存放到school_data.sql中。
