前两天配置服务器的时候，小心小心再小心的注意字符集问题，认认真真的在Server端配置了my.cnf，结果还是把Client端的事给忘了。进去的数据，依旧乱码。奋战两个小时，才找到问题，解决之。总结如下：

1，即使只安装了Client端，为了使MySQL默认使用UTF-8字符集，也需要在Client端的服务器上配置my.cnf

2，即使在Client端通过命令行方式连接Sever问题解决了，也不要侥幸的认为在用PHP连接的时候会正常。my.cnf只会影响MySQL的相关程序。

3，使用PHP连接MySQL时，使用“SET NAMES UTF8”，是个好习惯。

4，服务器端的my.cnf里，添加一行“init_connect = ‘SET NAMES utf8′”是个一劳永逸的办法。注意，root用户会忽略此参数。

参考：
http://www.toplee.com/blog/259.html
http://kevin.9511.net/archives/173.html

由于checksetup.pl脚本的存在，其实bugzilla的安装应该是非常顺利的，10多分钟，基本所有bugzilla需要的cpan扩展包都安装成功，最后出了一个数据库选择的提示。bugzilla目前可支持MySQL、PostgreSQL、Oracle三种数据库，需要要按自己的实际环境安装不同数据库的CPAN模块。所有的中文文档里，对这个步骤的形容都是跟其他模块一样，一条“/usr/bin/perl install-module.pl DBD::mysql”就可以搞定，可实际上……并非如此，起码我这么装没有成功，我个人估计，是因为他们安装Bugzilla的服务器跟mysql所运行的服务器在一台上面。我要安装Bugzilla的服务器，只编译安装了mysqlclient，并没有server存在。

在安装Bugzilla的时候，通过其提供的“install-module.pl”命令安装的CPAN模块，都是装在Bugzilla所在目录的lib目录下。而手动下载CPAN模块并安装的时候，在我的这台服务器上，默认是安装到“/usr/lib/perl5/5.8.5/”目录下的。这两个目录的结构相同。Bugzilla的checksetup.pl脚本在检测安装所需模块的时候，这连个路径都会扫描。

通过http://search.cpan.org搜索“DBD-mysql”，并下载“DBD::mysql”。解压缩后运行下面命令：

perl Makefile.PL –libs=”-L/usr/local/mysql-5.1.36/lib/mysql -lmysqlclient -L/usr/lib -lz” –cflags=-I/usr/local/mysql-5.1.36/include/mysql –mysql_config=/usr/local/mysql-5.1.36/bin/mysql_config –testhost=192.168.1.208 –testdb=test –testuser=bugs –testpassword=bugs

其中的“/usr/local/mysql-5.1.36”是安装mysqlclient的路径。在安装DBD::mysql的时候，会检测与mysql服务器的联通性，这里的testhost、testdb、testuser、testpassword就是做这个用的。用户bugs我事先在mysql服务器添加好了。

安装好“DBD::mysql”后，再次运行checksetup.pl脚本，出现了如下提示：

Reading ./localconfig…
Checking for       DBD-mysql (v2.9003) ok: found v4.005
Had to create DBD::mysql::dr::imp_data_size unexpectedly at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/DBI.pm line 1213, <DATA> line 228.
Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/DBI.pm line 1213, <DATA> line 228.
Had to create DBD::mysql::db::imp_data_size unexpectedly at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI.pm line 1243, <DATA> line 228.
Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI.pm line 1243, <DATA> line 228.
There was an error connecting to MySQL:

Undefined subroutine &DBD::mysql::db::_login called at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/mysql.pm line 142, <DATA> line 228.

在网上查了很长时间，按照网上的描述，修改localconfig文件n次，重新安装配置DBD::mysqln次，依然未果，而且就网上的说法，造成这个错误提示的原因有很多种。正在抓耳挠腮，郁闷之极的时候，突然看到一个邮件里表里有说mysql lib的问题。马上想到自己安装mysql的时候，是rpm卸载掉系统默认的4.0后，手动编译安装的mysql5.1。赶紧运行ldconfig，靠的，还真没有mysql的lib。修改/etc/ld.so.conf文件，把mysql的lib路径加进去，运行ldconfig。然后回到bugzilla目录重新运行checksetup.pl，一切哦耶了。

在中文论坛里，也看到一些人说mysql本来是4.x，bugzilla运行正常，后来升级成5.x之后，就出错了。这些错误应该也是跟我的问题一样，跟mysql的版本没什么关系。

关于ldconfig的问题，再次提醒下自己……http://kevin.9511.net/archives/177.html

MEDIUMTEXT 是 2G

LONGTEXT 是 4G .

MySQL 4.1开始把多国语言字符集分的更加详细，所以导致数据库迁移，或则dz论坛升级到4.0后（dz4.0开始使用gbk或utf-8编码）出现乱码问题。

MySQL 4.1的字符集支持(Character Set Support)有两个方面：字符集(Character set)和排序方式(Collation)。对于字符集的支持细化到四个层次: 服务器(server)，数据库(database)，数据表(table)和连接(connection)。

查看系统的字符集和排序方式的设定可以通过下面的两条命令：
QUOTE:
mysql> SHOW VARIABLES LIKE ‘character_set_%’;
+————————–+—————————-+
| Variable_name | Value |
+————————–+—————————-+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+————————–+—————————-+
7 rows in set (0.00 sec)

mysql> SHOW VARIABLES LIKE ‘collation_%’;
+———————-+——————-+
| Variable_name | Value |
+———————-+——————-+
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+———————-+——————-+
3 rows in set (0.00 sec)

MySQL 4.1 对于字符集的指定可以细化到一台机器上安装的 MySQL，其中的一个数据库，其中的一张表，其中的一栏，应该用什么字符集。但是，传统的 Web 程序在创建数据库和数据表时并没有使用那么复杂的配置，它们用的是默认的配置，那么，默认的配置从何而来呢？

编译 MySQL 时，指定了一个默认的字符集，这个字符集是 latin1；
安装 MySQL 时，可以在配置文件 (my.ini) 中指定一个默认的的字符集，如果没指定，这个值继承自编译时指定的；
启动 mysqld 时，可以在命令行参数中指定一个默认的的字符集，如果没指定，这个值继承自配置文件中的；
此时 character_set_server 被设定为这个默认的字符集；
当创建一个新的数据库时，除非明确指定，这个数据库的字符集被缺省设定为 character_set_server；
当选定了一个数据库时，character_set_database 被设定为这个数据库默认的字符集；
在这个数据库里创建一张表时，表默认的字符集被设定为 character_set_database，也就是这个数据库默认的字符集；
当在表内设置一栏时，除非明确指定，否则此栏缺省的字符集就是表默认的字符集；
这个字符集就是数据库中实际存储数据采用的字符集，mysqldump 出来的内容就是这个字符集下的；
当我们按照原来的方式通过PHP存取MySQL数据库时，就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询，你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。
想要进行“正确”的存储和得到“正确”的结果，最方便的是在所有query开始之前执行一下：

SET NAMES ‘gbk’;
其中gbk是数据库字符集。

它相当于下面的三句指令：
SET character_set_client = gbk;
SET character_set_results = gbk;
SET character_set_connection = gbk;

4.1和5.0默认使用的是latin1字符集(木头:妈的,老外真霸道,妄想让全世界都是使用瑞典字符集吗)
如果我们只想使用gbk字符集存储和获取数据,
我们在编译mysql 4.1和 5.0的时候，需要注意在my.ini或者my.cnf中添加两处参数
[mysqld]
default-character-set=utf8

#settings for clients (connection, results, clients)
[mysql]
default-character-set=utf8

下面我们来说主题，如何转换数据库字符集

更改存储字符集
主要的思想就是把数据库的字符集有latin1改为gbk，big5,或者utf8; 以下操作必须拥有主机权限。假设当前操作的数据库名为：database

导出
首先需要把数据导为mysql4.0的格式，具体的命令如下：
mysqldump -uroot -p –default-character-set=latin1 –set-charset=gbk –skip-opt databse > d4.sql

–default-characte-set 以前数据库的字符集，这个一般情况下都是latin1的，
–set-charset 导出的数据的字符集，这个可以设置为gbk，utf8,或者big5
导入
首先使用下面语句新建一个GBK字符集的数据库（test）

CREATE DATABASE `d4` DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci;
然后把刚才导出的数据导入到当前的数据库中就ok了。

mysql -uroot -p –default-character-set=gbk -f d4<d4.sql
通过以上的导出和导入就把数据库的字符集改为正确的存储方式了。

其中d4为新建库的名称，d4.sql为导出文件的名字

但是这种方法，发现数据库数据存储量无端变大30%，真是郁闷