Navicat for mysql 导出导入的问题

问题现象

 

1：使用navicat 导出5.6.20版本数据库，然后导入到5.7.19mysql出现错误：

 

 

 

 

 

 

 

解决办法：

上述错误有2类，1366错误和1067错误

 

一：1067错误

 

   建表语句有默认值，

 

 

 

5.7+的mysql数据库sql_mode 为严格模式，NO_ZERO_DATE设置该值则不允许插入的0日期，否则或报时间不能为0的错误,所以报错。

 

 

以下解决办法摘自网络：

1、表中的第一个timestamp如果没有设置默认为NULL，或者没有default，或者update字句，则自动分配default_current_timestamp和on update current_timestamp两个属性；

2、之后其他字段的timestamp字段，如果没有设置默认为NULL，或者是default字句，将自动分配为default（0000-00-00 00:00:00）零时间戳，不满足sql_mode中的NO_ZERO_DATE而报错。

注：sql_mode中有两种，一种是空值，一种是严格模式，mysql5.7以后的默认使用严格模式，NO_ZERO_DATE设置该值则不允许插入的0日期，否则或报时间不能为0的错误。

第一种：  select @@SQL_MODE，然后将查询出来的去掉NO_ZERO_DATE

                SET SQL_MODE = '去掉之后的值'。

                该方法只在当前的回话中的生效。（重新打开个命令窗口，SQL_MODE被还原）

第二种：select @@global.sql_mode ,将查询出的去掉NO_ZERO_DATE

               SET GLOBAL SQL_MODE = '去掉之后的值'，

               该方法只在当前服务中生效，当重启mysql服务后，则SQL_MODE 被还原

 

 

一：1366错误比较复杂，属于字符集转码问题，先学习mysql 字符集转换的知识：

 

 

     请看另一篇转载文章

 

https://blog.csdn.net/fdipzone/article/details/18180325

 

      

 

 

摘录重点过程

 

MySQL中的字符集转换过程

1. MySQL Server收到请求时将请求数据从character_set_client转换为character_set_connection；

2. 进行内部操作前将请求数据从character_set_connection转换为内部操作字符集，其确定方法如下：

• 使用每个数据字段的CHARACTER SET设定值；

• 若上述值不存在，则使用对应数据表的DEFAULT CHARACTER SET设定值(MySQL扩展，非SQL标准)；

• 若上述值不存在，则使用对应数据库的DEFAULT CHARACTER SET设定值；

• 若上述值不存在，则使用character_set_server设定值。

3. 将操作结果从内部操作字符集转换为character_set_results。

 

 

 

 

 

常见问题解析

• 向默认字符集为utf8的数据表插入utf8编码的数据前没有设置连接字符集，查询时设置连接字符集为utf8

– 插入时根据MySQL服务器的默认设置，character_set_client、character_set_connection和character_set_results均为latin1；

– 插入操作的数据将经过latin1=>latin1=>utf8的字符集转换过程，这一过程中每个插入的汉字都会从原始的3个字节变成6个字节保存；

– 查询时的结果将经过utf8=>utf8的字符集转换过程，将保存的6个字节原封不动返回，产生乱码……

 

 

 

 

向默认字符集为latin1的数据表插入utf8编码的数据前设置了连接字符集为utf8

– 插入时根据连接字符集设置，character_set_client、character_set_connection和character_set_results均为utf8；

– 插入数据将经过utf8=>utf8=>latin1的字符集转换，若原始数据中含有\u0000~\u00ff范围以外的Unicode字 符，会因为无法在latin1字符集中表示而被转换为“?”(0x3F)符号，以后查询时不管连接字符集设置如何都无法恢复其内容了。

 

 

看完上面摘录内容后，分析下上述操作出现 1366错误的原因：

 

 

目标数据库字符集如下：

 

 

源数据库字符集如下：

 

同样是utf8 字符集为什么会出现导入乱码呢？ 分析navicat导入的sql 文本，发现字段级字符集定义为GBK， 字符序（校对规则）为 GBK_BIN

 

 

导入的表结构定义：

 

 

 

是一样的，为什么会出现导入不成功的情况？

发现navicat 导入的 longtext 二进制数据存在丢失

 

 

 

 

 

 

 

 

 

在使用mysqldump 命令导出数据库，然后导入mysql，未出现任何error，查看mysqldump 导出的2进制数据：

 

 

 

 

 

从上面可以看到此次并非字符集问题导致的，而是处理大对象时候。navicat存在转码丢失、故导入失败、

在做数据库导出的时候，存在大对象的表，最好使用mysqldump工具。或者进行 cast 函数转换后导出，不推荐。

 

CAST(tb_blog.CONTENT AS char)