2)服务器端会把请求的数据从客户端字符集(character_set_client)转成服务器连接字符集(character_set_connection)。
3)然後服务器会检测存储区域(table，column)的字符集，然后把数据从连接字符集(character_set_connection)转为存储区域(table，column)的字符集，然後再存储或者查询。
2、返回请求。
1)服务器将存储区域(table，column)的字符集转换成服务器连接字符集(character_set_connection)。
2)将服务器连接字符集(character_set_connection)转换成结果字符集(character_set_results)，再发送到客户端。
例如，我建立一个字符集为 gbk 的数据库(服务器端)。(MySQL 4.1 开始，在建立数据库时要指定它的字符集和校对规则，不指定就用默认的字符集和校对规则。)
连接数据库的程序(客户端)使用 gb2312 字符集(如 windows 命令行下使用 MySQL ，或者 PHP 连接MySQL )，那么在执行 insert 命令时，insert 的字符串将做一个 gb2312 到 gbk 的转换。而 select 时，数据库中保存的数据会先经过 gbk 到 gb2312 的转换之后再给你(结果集)。
好，那么为什么升级3.23(或4.0)到4.1时会乱码?举个例子说明。
例如3.23的数据库中保存的是gbk编码的数据。升级之前我将这些数据导出保存到文件里，这个文件的编码当然也是gbk的(因为3.23不支持多语言，不会对数据进行转换，也就是前面说的“原封不动地保存，原封不动地读出)。
然后我在4.1中建立一个数据库，字符集为A;客户端字符集为B。将刚才的gbk数据导入。
1)A=gbk，B=gbk
导入数据时数据不会被转换;读出时需要set names gbk(set name命令下面将讲解)。
2)A=latin1，B=gbk
导入数据会进行gbk->latin1的转换，可能会丢失数据，产生乱码。
3)A=gbk，B=latin1
导入数据会进行latin1->gbk转换，可能会产生乱码。
4)A=latin1，B=latin1
导入数据时不会进行转换;读出时不需要set names gbk 。
大家可以看到，上面1)、4)才是正确的做法，即让A和B使用同样的字符集才不会乱码。
