公布关于MySQL字符集架构的思索
下面我将描述五个不使用MySQL的响亮理由。跟着各类多字节字符集的普遍使用，而在软件开辟里人数比例十分高的操英文的程序员对多字节字符并非很懂得，这是比来几年良多毛病都是多字节引发的一个缘故原由。本文作者就MySQL的字符集架构感化谈了本人的意见。 比来几个月，我每次用MySQL，几近城市想：MySQL如今云云井井有条的字符集架构感化真的很年夜吗？MySQL的字符集处置
发送哀求
客户端(character_set_client)=》数据库毗连(character_set_connection)=》存储(table,column)
前往哀求
存储(table,column)=》数据库毗连(character_set_connection)=》客户端(character_set_results)
在每个非初始节点，城市做一次从上一个结点到以后节点的字符集转换操纵。举个例子，有以下情况：
◆character_set_connectionutf-8
◆character_set_resultsgbk
◆character_set_clientgb2312
◆有表A，字段字符集全体为BIG5
发送哀求的时分，起首数据从gbk转换为utf-8，再转换为BIG5，然后再存储。
前往哀求的时分，起首数据从BIG5转换为utf-8，再转换为gb2312，然后再发送给客户端。
架构的感化
1.同意分歧的客户端具有分歧的字符集。典范的例子就是，我有一个utf-8的站点，这个站点就是一个charsetclient为utf-8的客户端。与此同时，我有大概必要在一个gbk的终端上读写数据库，这又是一个客户端，不外它的字符集是gbk。
2.经由过程数据库操纵文件体系的时分，必要把文件路径转为文件体系的字符集。比方我的客户端是gbk，而服务器文件体系是utf-8。操纵”/A片/Rina.rmvb”，发送已往的数据里，“片”的数据和服务器是纷歧样的。这时候候就必要有个举措能够把转换GBK的“片”到utf-8。在这里MySQL引进了一个叫character_filesystem的器材来完成这个事变。
除此以外，我临时想不到其他的感化了。可是细心想一想，我们真的必要如许的处置吗？良多网站，不过就是但愿本人的数据能怎样出来就怎样出来。这里又有两种情形了。
1.但愿能够依据数据举行排序大概做like操纵。起首说排序，关于包括中文的字段来讲，依据字符集排序的观点好像鸡肋。简体中文排序，一样平常都是但愿按拼音来排序。我没有往真正懂得过MySQL里的校验，可是从我打仗过的程序来看，必要做此类排序，都是专门建一个寄存拼音的字段来排序。而拼音又存在多音字的情形。假如是UTF-8，还存在某个区间的中文同时被中日韩三国共用的情形。完成起来不是这么简单，以是MySQL不管的GBK仍是UTF-8的校验集应当都没有完成拼音。我敢说，如今国际利用MySQL的年夜多半网站，所用到的校验集，只是一个byte排序罢了。而byte排序，基本不必要利用甚么字符集。以是说关于中文站点，MySQL字符校验在排序上没任何意义。
可是在like操纵上，却是有了一点点意义。比方我like‘%a%’，就有大概婚配到某其中文某个部分含有a。固然这类情形在utf-8下不会碰到，由于utf-8的存储格局招致a只多是a，不成能是一个多字节字符的一部分。可是在其他字符集大概就会有这个成绩了。说到最初，like又变得和order一样使得校验没意义了。晕倒。
2.假如完整不必要对数据举行排序，like大概全文检索，那末请中断利用char，varchar，text之类的吧。binary，varbinary，BLOB才是准确的选择。binary之类的在存储，掏出的时分都不会举行字符集转换，而在排序时分，只依据二进制内容排序，以是在效力上凌驾char，varchar，text良多。
这类情形更不必要字符集了。可是依照今朝MySQL的架构，在client和connection之间的字符集操纵，是疏忽字段范例的，在这两个节点之间，仍然会举行字符集转换。
别的提一下php里的设置字符集。人人请不要再利用mysql_query(”setnamesutf8″)如许的语句了。mysql_set_charset()才是最完全的字符集设置体例。后者比前者多一个设置，就是把structMySQL的charset成员也设置了。这个成员变量在escape的时分起着很主要的感化，出格是关于GBK这类运转把“”作为字符一部分的编码格局。假如你只利用mysql_query(”setnamesXXX”)，那末在某些字符集，会有严重的平安毛病，招致mysql_real_escape_string变得和addslashes一样不平安。
DBaaS系统其实具有更大的市场机遇：像其他云服务一样，DBaaS意味着更短的销售周期，更少的启动费用，持续不断的收入，也意味着比之前更多的客户。 无法深入到数据库系统层面去了解和探究 having子句的作用是筛选满足条件的组，即在分组之后过滤数据，条件中经常包含聚组函数，使用having条件显示特定的组，也可以使用多个分组标准进行分组。 另一个是把SQL语句写到服务器端,就是所谓的SP(存储过程); 微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。 你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。 备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。 还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。 外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。
页:
[1]