MySQL数据库中数据库移植中的乱码问题

核心提示： 先用head看一下SET NAMES在第几行（数一下），上面看到是第10行，MySQL数据库中数据库移植中的乱码问题(3)，wc -l EA192.060913.sql1987 EA192.060913.sql得到总行数是1987head -9 EA192.060913.sql >

先用head看一下SET NAMES在第几行（数一下），上面看到是第10行。

wc -l EA192.060913.sql
1987 EA192.060913.sql
得到总行数是1987
head -9 EA192.060913.sql > final.sql
brum@brum-laptop:~$ tail -1977 EA192.060913.sql
>> final.sql
brum@brum-laptop:~$

head -9是取前9行，tail -1977是取后1977行，这样就把第10行隔过去了。

得到final.sql再用MySQL运行时，就可以使用--default-character-set=gbk了。

还有一种办法是mysqldump时使用--set-charset=false，这样就不会出现SET NAMES了。

目前为止，还可能有问题，出在create table的SQL中，比如：

DROP TABLE IF EXISTS `test`;
CREATE TABLE `test` (
`a` varchar(100) default NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

这里仍然有个CHARSET=latin1，它将导致新创建的表的缺省字符集是latin1，而不是我们想要的UTF8。

怎么办呢，如果数据量不大的话，可以考虑用编辑器把它去掉或者改成UTF8，如果数据量大的话可以考虑用sed，但可能仍然时间比较长。

还有一种办法就是mysqldump，使用--create-options=false，不导出表的创建属性。但如果导出的表的存储引擎不同的话就有问题了，因为引擎类型（innodb、myisam等）都被忽略了。

此外，mysqldump导出时，不要使用-B，而是直接指定一个database名字，目的是不出现CREATE DATABASE语句，因为其中也可能会有缺省字符集的子句，会影响那些未在CREATE TABLE中指定字符集的表。如果你导出的SQL中有CREATE DATABASE，那么需要注意一下有没有字符集的子句，如果有的话，也需要修改。

好了，通过上述方法导出或者处理过的导出文件可以使用mysql --default-character-set=gbk来导入了。