MySQL字符集和copy_and_convert_MySQL
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了MySQL字符集和copy_and_convert_MySQL，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2314字，纯文字阅读大概需要4分钟。
内容图文
bitsCN.com
MySQL字符集和copy_and_convert
关于copy_and_convert
在对MySQL做业务压力测试的时候，我们在perf结果中发现 copy_and_convert 是一个耗费cpu的操作。这个函数的意思，就是在字符集之间做内容转换。
如果源和目标的字符集相同，就可以直接用memcpy，这显然比做字符集转换（按字节或字长拷贝更快，和节省cpu）
当整个系统是CPU瓶颈时，我们希望能够减少这种cpu消耗。
一次查询涉及的拷贝
如果我们执行一个简单的select语句，会涉及到两部分的内容：metadata和data。MySQL的返回包是能够“自解析”的，也就是说不仅有内容，还有描述信息。这些描述信息我们称为metadata。
在将这两部分信息返回给客户端的时候，就涉及到字符串拷贝，如果源字符集和目标字符集不同，就需要作转换。
字符集里面可以定义的部分
1、 表的字符集
比如我们创建如下的表
CREATE TABLE `t` (
`c` int(11) DEFAULT NULL,
`d` varchar(50) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=gbk;
这就定义了这个表的字符集，要求存入数据按照gbk格式存储。在我们查询的时候，从表中读出的数据，就是我们上文说到的“源字符集”，在这里是gbk.
比如
Insert t values(2012, ‘南方很冷’);
2、连接字符集
在连接的时候我们可以在mysql客户端指定参数 mysql -default-character-set=gbk ，表示我们接收的内容希望是gbk编码，这个就是上文说的“目标字符集”。
一般我们会被建议：连接字符集和表字符集相同。
有的文章说防止乱码—-乱码倒是不会，实际的原因就是在内容拷贝时避免字符集转换计算。
本文要说的“但是”
但是即使这么做，在压力测试（或者你gdb）时，还是会发现会调用到 copy_and_convert。
原因有二：
首先，metadata部分，是固定的使用utf8，这个值可以从show variables like ‘character_set_system’;的结果看到，hardcode，配置无法修改。
其次，虽然我们定义表字符集是gbk, 但是整型字段是是Latin1存储，
#define my_charset_numeric my_charset_latin1，配置无法修改。
因此在我们上面的设置中，一次查询，在传回metadata的时候需要utf8->gbk, 返回结果中c这个字段需要latin1->gbk.
问题和建议
从上面分析知道，这存在的问题就是，无论用户怎么设置，都无法完全避免这种转换。
由于数字类型转成字符串后，使用什么字符集都占用一样的空间。
1) 在代码上最简单的修改可以如下：
将 #define my_charset_numeric my_charset_latin1 改成
#define my_charset_numeric my_charset_utf8_general_ci
这样跟metadata部分相同，然后建表和客户端都是使用utf-8。
2) 更灵活一点是把character_set_system改成可配置，然后整型存储按照用户定义的字符集。
bitsCN.com
内容总结
以上是互联网集市为您收集整理的MySQL字符集和copy_and_convert_MySQL全部内容，希望文章能够帮你解决MySQL字符集和copy_and_convert_MySQL所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。