算来我也是mysql的忠实用户了,从mysql 3 的时候就开始用mysql,直到现在开始使用5.1版本,看到mysql一点一点的变化,感觉mysql功能越来越强大,真是是我们这种用不起oracle用户的福音啊!
如果没有记错的话,mysql4.0升级到4.1以后,就增加了字符集这个概念。从mysql4.0及以下的版本,迁移到mysql4.1及其以上的版本就会出现中文字符出现乱码的问题。由于以前mysql的编码是latin1 SW (好像是瑞典字符集——mysql是由瑞典人开发的,估计当时没有考虑国际化的问题),现在我们用的编码一般是gbk或者utf8。那么以前latin1编码的表中的中文怎么迁移到gbk或者utf8编码的表中呢?直接更改表的编码是没有任何作用的,参考了一些资料,说是mysql在更改表编码的时候,不会对表中现有数据进行转码。
网上有很多怎么进行转码的资料和程序,感觉都不是很方便。比较BT的就是用PHP,一行一行的从mysql的源表中读出来,再利用PHP进行转码,然后再查到目标表中。想想这样做确实有用。但是性能惨不忍睹……小表还可以这么做,要是上百万行记录的表,非等上几个小时不可,实在太浪费时间。
好了,前面都是废话,俺就贡献一下俺的研究吧:
首先,到mysql\bin 下面,利用mysqldump这个工具,执行以下命令:
[code]mysqldump --u=root -p --default-character-set=latin1 --set-charset=utf8 --skip-opt --result-file=c:\mytable.sql mydb mytable[/code]
其中:root 为数据库登录名, latin1 为源表(就是想进行转码的表)的编码, utf8 为想转换成的编码, c:\mytable.sql 为导出的数据的存放文件(临时用), mydb是源表所属的数据库(schema),mytable 就是源表名了
执行这条命令,会提示输入密码,输入正确的密码以后,就开始导出数据了。等到数据全部导出以后,可以用ue等工具打开,这时可以看到这些数据的编码已经转变了。
然后需要对这个文件进行一点点更改。在文件的最开头有一个建表语句。类似于:
[code]CREATE TABLE `mytable` (
`tableid` bigint(20) unsigned NOT NULL,
`c1` int(10) unsigned NOT NULL default '0',
`c2` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`tableid`)
);[/code]
注意看最后的分号,缺少了一点点东西:[b]engine=myisam DEFAULT CHARSET=utf8[/b] engine 和 charset 的意义地球人都知道啊... 将这一段加进去。结果可能是这样:
[code]CREATE TABLE `mytable` (
`tableid` bigint(20) unsigned NOT NULL,
`c1` int(10) unsigned NOT NULL default '0',
`c2` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`tableid`)
) engine=myisam DEFAULT CHARSET=utf8;[/code]
其中engine 和 charset 改成期望的东西,如:innodb gbk 等...
保存文件。(如果是用UE等工具即使文件大也不会等太久,如果用记事本打开的……恭喜你! :wink: )
这样就成功了一半了,剩下的工作只需要导入这个转好码的数据了。
将原来的那个表改名,一是为了备份,二是防止导入的时候说表已经存在。
然后还是进入mysql\bin 下面,运行:
[code]mysql -u root -p mydb < c:\mytable.sql[/code]
输入密码以后程序开始工作,一段时间以后,新表就出来咯...
mission complete!
如果没有记错的话,mysql4.0升级到4.1以后,就增加了字符集这个概念。从mysql4.0及以下的版本,迁移到mysql4.1及其以上的版本就会出现中文字符出现乱码的问题。由于以前mysql的编码是latin1 SW (好像是瑞典字符集——mysql是由瑞典人开发的,估计当时没有考虑国际化的问题),现在我们用的编码一般是gbk或者utf8。那么以前latin1编码的表中的中文怎么迁移到gbk或者utf8编码的表中呢?直接更改表的编码是没有任何作用的,参考了一些资料,说是mysql在更改表编码的时候,不会对表中现有数据进行转码。
网上有很多怎么进行转码的资料和程序,感觉都不是很方便。比较BT的就是用PHP,一行一行的从mysql的源表中读出来,再利用PHP进行转码,然后再查到目标表中。想想这样做确实有用。但是性能惨不忍睹……小表还可以这么做,要是上百万行记录的表,非等上几个小时不可,实在太浪费时间。
好了,前面都是废话,俺就贡献一下俺的研究吧:
首先,到mysql\bin 下面,利用mysqldump这个工具,执行以下命令:
[code]mysqldump --u=root -p --default-character-set=latin1 --set-charset=utf8 --skip-opt --result-file=c:\mytable.sql mydb mytable[/code]
其中:root 为数据库登录名, latin1 为源表(就是想进行转码的表)的编码, utf8 为想转换成的编码, c:\mytable.sql 为导出的数据的存放文件(临时用), mydb是源表所属的数据库(schema),mytable 就是源表名了
执行这条命令,会提示输入密码,输入正确的密码以后,就开始导出数据了。等到数据全部导出以后,可以用ue等工具打开,这时可以看到这些数据的编码已经转变了。
然后需要对这个文件进行一点点更改。在文件的最开头有一个建表语句。类似于:
[code]CREATE TABLE `mytable` (
`tableid` bigint(20) unsigned NOT NULL,
`c1` int(10) unsigned NOT NULL default '0',
`c2` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`tableid`)
);[/code]
注意看最后的分号,缺少了一点点东西:[b]engine=myisam DEFAULT CHARSET=utf8[/b] engine 和 charset 的意义地球人都知道啊... 将这一段加进去。结果可能是这样:
[code]CREATE TABLE `mytable` (
`tableid` bigint(20) unsigned NOT NULL,
`c1` int(10) unsigned NOT NULL default '0',
`c2` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`tableid`)
) engine=myisam DEFAULT CHARSET=utf8;[/code]
其中engine 和 charset 改成期望的东西,如:innodb gbk 等...
保存文件。(如果是用UE等工具即使文件大也不会等太久,如果用记事本打开的……恭喜你! :wink: )
这样就成功了一半了,剩下的工作只需要导入这个转好码的数据了。
将原来的那个表改名,一是为了备份,二是防止导入的时候说表已经存在。
然后还是进入mysql\bin 下面,运行:
[code]mysql -u root -p mydb < c:\mytable.sql[/code]
输入密码以后程序开始工作,一段时间以后,新表就出来咯...
mission complete!