C++博客-yg2362-随笔分类-数据库

C++博客-yg2362-随笔分类-数据库http://www.cppblog.com/yg2362/category/20221.htmlzh-cnThu, 06 Dec 2012 15:16:46 GMTThu, 06 Dec 2012 15:16:46 GMT60大区中分配玩家唯一ID的办法(续)http://www.cppblog.com/yg2362/archive/2012/12/06/196061.html梨树阳光梨树阳光Thu, 06 Dec 2012 15:01:00 GMThttp://www.cppblog.com/yg2362/archive/2012/12/06/196061.htmlhttp://www.cppblog.com/yg2362/comments/196061.htmlhttp://www.cppblog.com/yg2362/archive/2012/12/06/196061.html#Feedback0http://www.cppblog.com/yg2362/comments/commentRss/196061.htmlhttp://www.cppblog.com/yg2362/services/trackbacks/196061.html 之前因为时间匆忙，大区里产生唯一ID只是简单写了一个方法，今天趁着有时间，把里面一些过程写出来，也算是个总结。
首先说说需求，现在游戏里数据库为了分散热点，都采用分表方式，以前那种一张表AUTO_INCREMENT的方式显然不行了，那么将唯一ID放到业务进程里可行吗？这个也不好，因为现在后台都是多个部署，每个进程可以保证ID唯一，但是存到数据库的时候就可能重复，所以我们还是得在DB上做文章。
因此就有了上篇文章的解决方案，单独一张表，这张表的作用就是专门产生唯一ID，而且为多个业务提供唯一ID，多进程情况下也不需要锁表，效率比较高，是不是很像设计模式里的工厂。接着我来分析下这张表。我们再来看看表结构和用法
create table SeqTab (
iSeqNo bigint(20) not null default 0, //表示唯一ID
iSeqType int(11) not null default 0, //表示业务ID
primary key(iSeqNo,iSeqType));
insert into SeqTab values(0,1); //初始化，假设一个业务编号为1
update SeqTab set iSeqNo=last_insert_id(iSeqNo+1) where iSeqType=1;
select last_insert_id(); //这两句是获取一个业务的唯一ID，供业务进程使用。
其实说到这张表，关键是说LAST_INSERT_ID()这个方法。它有两种形式LAST_INSERT_ID()，LAST_INSERT_ID(expr)。
这个东西的特点是，1.属于每个CONNECTION，CONNECTION之间相互不会影响 2.不属于某个具体的表 3.返回最后一次INSERT AUTO_INCREMENT的值 4.假如以此使用INSERT插入多行数据，只返回第一行数据产生的值 5.如果你UPDATE某个AUTO_INCREMENT的值，不会影响LAST_INSERT_ID()返回值
LAST_INSERT_ID(expr)与LAST_INSERT_ID()稍有不同，首先它返回expr的值，其次它的返回值会记录在LAST_INSERT_ID()。
我们这里主要使用到了第一和第二个特点，每个进程并发执行update SeqTab set iSeqNo=last_insert_id(iSeqNo+1) where iSeqType=1;,就获取属于进程自己的iSeqNo并且记录在 LAST_INSERT_ID中，通过第二句取出该值。
接着我们在比较下其他一些办法。
第一种是直接一张表，里面有一个ID字段，设置成AUTO_INCREMENT。这个的问题是每个业务ID不是连续的，是离散的。
第二种是使用GUID或者UUID，但是这个问题我个人觉得是效率上的差异，字符串没有数字的效率好，另外数字ID今后也可以拼接一些区信息，之后跨区的时候可以方便获取对象是哪个区的.

梨树阳光 2012-12-06 23:01 发表评论

]]>大区中分配玩家唯一ID的办法http://www.cppblog.com/yg2362/archive/2012/12/05/196002.html梨树阳光梨树阳光Wed, 05 Dec 2012 03:54:00 GMThttp://www.cppblog.com/yg2362/archive/2012/12/05/196002.htmlhttp://www.cppblog.com/yg2362/comments/196002.htmlhttp://www.cppblog.com/yg2362/archive/2012/12/05/196002.html#Feedback2http://www.cppblog.com/yg2362/comments/commentRss/196002.htmlhttp://www.cppblog.com/yg2362/services/trackbacks/196002.htmlMysql中除了使用auto_increment字段作为自增序号以外还有另外一种办法可以提供唯一序列号并且可以由一张表完成对多个序列

要求的满足。

大致如下：

1.创建一个简单表

create table SeqTab

( iSeqNo int not null default 0,

iSeqType int not null default 0);

2.插入一调记录

insert into SeqTab values(0,13); // 0表示SeqNo初始值，13为SeqType，同一张表可对多个应用提供Seq序列服务

3.不管多进程 or 单进程对SeqTab表同时进行访问，使用一下方法获取序列号

1st->update SeqTab set iSeqNo=last_insert_id(iSeqNo+1) where iSeqType=13;

2nd->select last_insert_id();

4.因多进程对SeqTab同时访问，进行update SeqTab set iSeqNo=last_insert_id(iSeqNo+1);时，数据库保证了update的事务

完整性，且last_insert_id()是与当前mysql连接相关的，所以多进程同时使用时，也不会冲突。

梨树阳光 2012-12-05 11:54 发表评论

]]>mysql中文乱码解析http://www.cppblog.com/yg2362/archive/2012/11/26/195711.html梨树阳光梨树阳光Mon, 26 Nov 2012 11:56:00 GMThttp://www.cppblog.com/yg2362/archive/2012/11/26/195711.htmlhttp://www.cppblog.com/yg2362/comments/195711.htmlhttp://www.cppblog.com/yg2362/archive/2012/11/26/195711.html#Feedback2http://www.cppblog.com/yg2362/comments/commentRss/195711.htmlhttp://www.cppblog.com/yg2362/services/trackbacks/195711.html相信大家在开发后台的过程中都遇到过中文乱码的问题，今天我就来讲讲其中的原因。
我这建了3张表，test_latin1,test_utf8,test_gbk,表结构如下
+-------+----------+------+-----+---------+-------+

+-------+----------+------+-----+---------+-------+

+-------+----------+------+-----+---------+-------+

我的前端是gbk的编码
执行下面的语句
set names 'latin1'
insert into test_latin1 set name='王';('王'字是GBK编码)
select name from test_latin1;
结果是否为乱码？

执行下面的语句

set names 'gbk'
insert into test_latin1 set name='王';('王'字是GBK编码)
select name from test_latin1;
结果是否为乱码？

  执行下面的语句
set names 'latin1'
insert into test_utf8 set name='王';('王'字是GBK编码)
select name from test_utf8 ;
结果是否为乱码？

我们举个例子，假设一个汉字的字符编码为0xFFFF，它在屏幕上能够正常显示，如果汉字存入数据库的时候和从数据库中取出的时候，编码一致，那么它肯定不是乱码。反过来，如果输出的时候是乱码，那么它肯定被转码了，至于为什么被转码了，我们得看看mysql里面做了什么(mysql难道会把无码片变成了有码片？)
首先mysql里面有2个概念，一个叫character set,一个叫collation。我们先说说character set。字符集就是数字，英文字符，汉字等编码格式，我们常见的是utf8,gbk,gb2312。mysql里面比较复杂，有4个东西跟它有关，分别是character_set_client，character_set_connection，character_set_database，character_set_results。set names (latin1)其实就是character_set_client=latin1，character_set_connection=latin1，character_set_results=latin1，它的流程是character_set_client ==> character_set_connection ==> Table Character ==> character_set_results。
我们按照上面的流程，来分析第一个问题。
      set names 'latin1'----执行了character_set_client=latin1，character_set_connection=latin1，character_set_results=latin1;
      insert into test_latin1 set name='王';这句话，mysql做了什么事呢？首先，character_set_client,它会把王字的编码当成latin1的编码传递给character_set_connection（此时不会转码），character_set_connection会把编码传递给Table Character,因为表本身是latin1，所以此时也不需要转码，select name from test_latin1;mysql会把test_latin1中的编码传递给前端，此时也不需要转码，所以，走个流程下来，我们输入的是什么编码，输出的还是相同的编码，因此，第一个问题的答案是不会是乱码。我画个流程图latin1==>latin1==>latin1==>latin1,没有转码的过程

我们在来看第二个问题。
  set names 'test_gbk'----执行了character_set_client=gbk，character_set_connection=gbk，character_set_results=gbk;
  insert into test_latin1 set name='王';character_set_client,它会把王字的编码当成gbk的编码传递给character_set_connection（此时不会转码）,character_set_connection会把编码传递给Table Character,因为表是lanti1的编码格式，这个过程的时候就会进行转码，但是latin1的字符集小于gbk的字符集，所以它会找不到对应字符的编码，此时会以？代替。select name from test_latin1，此时会从latin1转码成gbk,但是此时latin1已经是错误的数据了，所以得到的gbk编码也是错误的了。流程gbk==>gbk==>latin1==>gbk,其中gbk==>latin1出了问题，我们select出来的数据也就不可能是输入时候的数据了。因此，这个问题的答案是乱码。

第三个。
  set names 'test_latin1'
  insert into test_utf8 set name='王';character_set_client,它会把王字的编码当成latin1的编码传递给character_set_connection（此时不会转码）,character_set_connection会把编码传递给Table Character,此时表是utf8的格式，因此会进行转码，latin1==>utf8,因为utf8的字符集>latin1字符集，因此，转码正常。select name from test_utf8;会从utf8转码成latin1,此时可以转码成功，因此我们最终得到的和输入的时候是一致的，因此答案不是乱码。流程latin1==>latin1==>utf8==>latin1,从小的字符集到大的字符集再到小的字符集，转码是不会有问题的。
屁话了这么多，无非想告诉大家一个万精油方法，表创建的字符集和set names都设置成同一个字符集，就基本可以满足输入数据不会在转换过程中失真，也就是说输入是什么，输出就是什么。建议有中文的都设置成utf8字符集，一劳永逸。

梨树阳光 2012-11-26 19:56 发表评论

]]>