关于mysql的字符集架构
看了http://item.feedsky.com/~feedsky/phpv/~1232318/176981487/1235221/1/item.html
的这篇文章，整理了下觉得这些对我很有帮助，记录一下
MySQL的字符集处理是这样的：
1）发送请求
客户端(character_set_client）=》数据库连接(character_set_connection)=》存储(table,column)
2）返回请求
存储(table,column)=》数据库连接(character_set_connection )=》客户端(character_set_results)
在每一个非初始节点，都会做一次从上一个结点到当前节点的字符集转换操作。举个例子，有如下环境：
* character_set_connection utf-8
* character_set_results gbk
* character_set_client gb2312
* 有表A，字段字符集全部为BIG5
发送请求的时候，首先数据从gbk转换为utf-8，再转换为BIG5，然后再存储。
返回请求的时候，首先数据从BIG5转换为utf-8，再转换为gb2312，然后再发送给客户端。
如果完全不需要对数据进行排序，like或者全文检索，那么请停止使用char，varchar，text之类的吧。 binary，varbinary，BLOB才是正确的选择。binary之类的在存储，取出的时候都不会进行字符集转换，而在排序时候，只根据二进制内 容排序，所以在效率上高出char，varchar，text很多
另外提一下PHP里的设置字符集。大家请不要再使用mysql_query(”set names utf8″)这样的语句了。mysql_set_charset()才 是最完整的字符集设置方式。后者比前者多一个设置，就是把struct MySQL的charset成员也设置了。这个成员变量在escape的时候起着很重要的作用，特别是对于GBK这种运行把“\”作为字符一部分的编码格式。如果你只使用mysql_query(”set names XXX”)，那么在某些字符集，会有重大的安全漏洞，导致mysql_real_escape_string变得和addslashes一样不安全。