mysql乱码现象及对字符集的理解
数据库版本是5.7.17
现象1
Navicat Premium导sqlserver数据到MySQL时，发现一些表只导了表结构没有导入数据，一些表导入了部分数据，一些表数据全部导入成功
查找原因：
1.发现导入成功的数据都是没有任何中文的
2.在mysql上删除只导了表结构没有导入数据的表A，使用Navicat Premium重新表A，查看Navicat Premium导入日志[Err] [Row1] [Imp] 1366 - Incorrect string value: '\xE6\xAD\xA3\xE5\xB8\xB8...' for column 'colunmname1' at row 1
3.在sqlserver上查看select colunmname1 from A发现都是中文内容
至此查出原因：就是因为简体中文的原因，导致没有导入成功
解决方法
方法1：在mysql上查询表A的建表语句show create table A，发现建表语句最后是CHARSET=latin1，重新修改表A的建表语句把CHARSET=latin1改成CHARSET=utf8，再删除表A，再重新建立表A,再导表就OK了
方法2：mysql -uroot -p123456
mysql>show variables like 'char%';发现库里面的字符集character_set_database是latin1
修改/etc/my.cnf新增如下配置
[mysqld]下新增character-set-server=utf8
[mysql]下新增default-character-set=utf8
[client]下新增default-character-set=utf8
service mysqld restart
再在mysql上drop导入没有完全成功的表，再重新导表（当然在个人实验中，导入还是继续报错的，因为mysql -uroot -p123456进去后没有选择库,修改后只是新增库的字符集会变成utf8，当然选择了库也没用，虽然重启了数据库，但表A对应的库如DATABASEA是修改配置之前建立的，它的字符集还是latin1，除非重建DATABASEA把字符集修改为utf8，这样风险太高，里面的东西都得重新弄过一次）
现象2
mysql字符集都是utf8了，但是在个人的windows机器上使用SQLyogEnt查询表A，发现中文乱码，加上语句后SET character_set_results=gbk后才不乱码
而在个人的windows机器上使用putty登录mysql服务器使用mysql>查询发现表A不乱码
原因：
个人电脑cmd输入chcp值是936对应简体中文
mysql服务器echo $LANG显示是zh_CN.UTF-8
在windows上通过工具SQLyogEnt连接mysql查询，其实是在windows上查询，使用的是windows的字符集gbk，但是mysql字符集是utf8，所以会乱码
在windows上通过putty连接mysql服务器查询，其实就是在mysql服务器端查询，mysql服务器字符集UTF-8，mysql字符集是utf8，所以不会乱码
理解
1.mysql安装后数据库字符集默认是latin1
2.my.cnf修改字符集配置并重启后，只是对新增的库生效，老库还是latin1，老库新增表也还是随老库latin1
3.库和表的字符集可以不一样，遇到问题评估下是重导表还是重导库
分享名称：mysql乱码现象及对字符集的理解
网页链接：http://ybzwz.com/article/jphoos.html
现象1
Navicat Premium导sqlserver数据到MySQL时，发现一些表只导了表结构没有导入数据，一些表导入了部分数据，一些表数据全部导入成功
查找原因：
1.发现导入成功的数据都是没有任何中文的
2.在mysql上删除只导了表结构没有导入数据的表A，使用Navicat Premium重新表A，查看Navicat Premium导入日志[Err] [Row1] [Imp] 1366 - Incorrect string value: '\xE6\xAD\xA3\xE5\xB8\xB8...' for column 'colunmname1' at row 1
3.在sqlserver上查看select colunmname1 from A发现都是中文内容
至此查出原因：就是因为简体中文的原因，导致没有导入成功
解决方法
方法1：在mysql上查询表A的建表语句show create table A，发现建表语句最后是CHARSET=latin1，重新修改表A的建表语句把CHARSET=latin1改成CHARSET=utf8，再删除表A，再重新建立表A,再导表就OK了
方法2：mysql -uroot -p123456
mysql>show variables like 'char%';发现库里面的字符集character_set_database是latin1
修改/etc/my.cnf新增如下配置
[mysqld]下新增character-set-server=utf8
[mysql]下新增default-character-set=utf8
[client]下新增default-character-set=utf8
service mysqld restart
再在mysql上drop导入没有完全成功的表，再重新导表（当然在个人实验中，导入还是继续报错的，因为mysql -uroot -p123456进去后没有选择库,修改后只是新增库的字符集会变成utf8，当然选择了库也没用，虽然重启了数据库，但表A对应的库如DATABASEA是修改配置之前建立的，它的字符集还是latin1，除非重建DATABASEA把字符集修改为utf8，这样风险太高，里面的东西都得重新弄过一次）
现象2
mysql字符集都是utf8了，但是在个人的windows机器上使用SQLyogEnt查询表A，发现中文乱码，加上语句后SET character_set_results=gbk后才不乱码
而在个人的windows机器上使用putty登录mysql服务器使用mysql>查询发现表A不乱码
原因：
个人电脑cmd输入chcp值是936对应简体中文
mysql服务器echo $LANG显示是zh_CN.UTF-8
在windows上通过工具SQLyogEnt连接mysql查询，其实是在windows上查询，使用的是windows的字符集gbk，但是mysql字符集是utf8，所以会乱码
在windows上通过putty连接mysql服务器查询，其实就是在mysql服务器端查询，mysql服务器字符集UTF-8，mysql字符集是utf8，所以不会乱码
理解
1.mysql安装后数据库字符集默认是latin1
2.my.cnf修改字符集配置并重启后，只是对新增的库生效，老库还是latin1，老库新增表也还是随老库latin1
3.库和表的字符集可以不一样，遇到问题评估下是重导表还是重导库
分享名称：mysql乱码现象及对字符集的理解
网页链接：http://ybzwz.com/article/jphoos.html
