Mysql“海量”数据库的编码转换，成功案例 Latin1到Utf8
这些应用都不能算是海量了。大小也只是2个G，转换后成功率99.97%，重要的数据都对比了条数，没有缺少，很是欣慰。
之前自己写了一个脚本，直接转换Mysql，没有先把数据存下来的那种，每次设定转换一定的数据量，不过只能适合普通的几十M的转换，除非CPU比较高。
源码如下：
不过不建议用这个，只能说自己的水平比较有限，没有考虑到编码转换等的种种问题。
经过研究发现：先把数据库备份下来再恢复是最佳的方案。
之前记得有个帝国备份王的。感觉不错，于是就在上面做了一些修改：
原版（开源）：帝国备份王2008
修改了里面一个文件：class下面的functions.php就可以解决问题了。
下面附上functions.php的代码：
这样子，就可以解决一两个G的数据库备份，转码等问题。
过程中，发现帝国备份王比其他的备份工具都要快，原因是因为我选择了按照条数来限制每次导出量，并且自动识别了主键。
在SQL查询是如何体现的呢？
核心代码如下：
Select * From yanxue8_visit Where vid >=(
Select vid From yanxue8_visit Order By vid limit 10,1
) limit 10
简单吧，更多的内容可以参照：
http://www.phpobject.net/blog/read.php/119.htm
此外，也有用命令行来做编码转换的，核心的导出：
以原来的字符集为latin1为例，升级成为utf8的字符集。原来的表: old_table (default charset=latin1)，新表：new_table(default charset=utf8)。
第一步：导出旧数据
mysqldump –default-character-set=latin1 -hlocalhost -uroot -B my_db –tables old_table > old.sql
第二步：转换编码(类似unix/linux环境下)
iconv -t utf-8 -f gb2312 -c old.sql > new.sql
或者可以去掉 -f 参数，让iconv自动判断原来的字符集
iconv -t utf-8 -c old.sql > new.sql
在这里，假定原来的数据默认是gb2312编码。
事实证明这个不明智，超过两个G的SQL文件，转码慢，无法一次打开，无法修改，用命令导入的时候Mysql经常自己掉线，最可怕的是数据丢失严重。我之前也是打算用命令行来转换后院的数据库的，后来发现，不行，丢失数据的情况很严重，然后自己写然后再出现了本文开头的那一幕。
分别学到的PHP跟MySQL语法有：
- 识别当前字段类型 mysql_field_type
- 识别当前字段属性 mysql_field_flags（一般是判断是否是二进制，如果是就用base64_encode，导入的时候用base64_decode，这个是一个笨办法 :~ ）
- 在中文的系统，导出的SQL如果正常显示中文就说明已经是gbk的格式（ANSI文件格式），这个时候只要用 “character_set_client=’binary’; ENGINE=MYISAM DEFAULT CHARSET=gbk;” 就可以了。千万不要与目标编码对齐。
- 可以看备份王里面关于生成文件编码的处理，确实很优秀，值得学习跟推荐。
