又做了一次道学百科的数据库迁移。从本地到服务器上。

因为上次做过一次，本来以为很简单，把原来的s数据库备份，或者读出来，然后再导入就OK了

实际操作中，却不是哪么简单，中间出了问题多问题，当然也对mysql了解更多。

先说一个问题，建立数据库的时候，所有的编码一定要一致，不然就是自找麻烦。mysql的编码很多种，包括连接编码，字符集编码，数据库编码，表编码，以及数据编码。 这次出现问题的就是表编码。

本来建数据的时候，数据库连接选的是uft8，然后数据库的编码使用默认（默认就是那个该死的latin1），后来发现不对劲，就整理了一下，结果数据库整理成了uft8，表还是latin1，当时没怎么注意，后来才发现这是个大问题。

上次数据导入的时候，因为出现编码问题（主要是保持的数据库文件的编码），使用的是直接复制sql语句，这次就使用了iconv转换sql文件，结果是不行，导入完毕后mediawiki能运行，但是没有任何词条（上次是有词条，但是乱码），首页都是空的。
到数据库里看了一下，发现数据都是乱码，而且表的编码都是latin1。心想还是不会是导入的时候就是这样的吧，到sql文件中一看，果然语句中的数据都是乱码。使用phpmyadmin查看本地的数据库，数据也是乱码。
这个问题比较严重，查了一下网络，发现都是将导出的sql文件进行编码转换，然后进行导入，然后再设置。对于导出就是乱码的，
有一个方法就是使用mysqldump，有文章说使用–default-character-set，后边要跟数据表的编码，不然导出的数据可能会乱码，但是试验了几次，均告失败，无论咋搞，导出来的数据都是乱码。

后来实在是无奈了，而原来数据库也不敢大动，于是把数据库data目录下的文件复制了一份放到了本本上，然后搭建一个环境，竟然能用。。。。 无语了，这也行。
本来这时候就想告终了，让空间商直接把那个目录给覆盖一下完事了，但是想想还要等到晚上，实在是等不了。于是继续寻找方案。
中间问了几次同事，把几十张表，手工改成了uft8，但是里面有些数据还是latin1的，导出的时候，既然是乱码。

在反复折腾mysqldump  iconv 和phpmyadmin的过程中，尝试了很多方式和参数，但是始终搞不定，后来又用mysql front 和navicat，
发现对表的操作也没有比较好的办法。 无奈ing

无聊中，开始看front和navicat的官方网站，希望能够找到相应的功能，front的导出会有一些编码选择，搞了半天也没明白那些编号的意义
都是写465xx 464xx之类的，后面的看不见，前面是调用系统的mlang.dll 。google了2小时，放弃了。
navicat竟然有一个数据传输功能，看了一下，竟然是进行数据库copy的，从一个库传输到另外一个。或许可以解决我的问题，不管乱码不乱码，因为网站原来的正常的，只要保证正常就行。于是赶紧连接上一试。

短短的几分钟过去，提示传输完成。打开网站，一切正常。

整个过程，折腾了2天一夜。

发表于 @ 2008年04月30日　11:30:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:BREW 介绍 | 新一篇:今天