其实针对使用自增长还是UUID,大家讨论最多的就是速度和存储空间,这里我加入了安全性和分布式,具体对比如下: 使用自增长做主键的优点:1.很小的数据存储空间2.性能最好3.容易记忆使用自增长做主键的缺点:1.如果存在大量的数据,可能会超出自增长的取值范围2.很难(并不是不能)处理分布式存储的数据表,尤其是需要合并表的情况下3.安全性低,因为是有规律的,容易被非法获取数据使用GUID做主键的优点:1.它是独一无二的,出现重复的机会少2.适合大量数据中的插入和更新操作,尤其是在高并发和分布式环境下3

测试缘由 一个开发同事做了一个框架,里面主键是uuid,我跟他建议说mysql不要用uuid用自增主键,自增主键效率高,他说不一定高,我说innodb的索引特性导致了自增id做主键是效率最好的,为了拿实际的案例来说服他,所以准备做一个详细的测试.  作为互联网公司,一定有用户表,而且用户表UC_USER基本会有百万记录,所以在这个表基础上准测试数据来进行测试.           测试过程是目前我想到的多方位的常用的几种类型的sql进行测试,当然可能不太完善,欢迎大家留言提出更加完善的测试方案或

  主键类型 SQL语句 运行时间 (秒)   (1)模糊范围查询1000条数据,自增ID性能要好于UUID 自增ID SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`MOBILE` LIKE '147%' LIMIT 1000; 2.398 UUID SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` LIKE '147%' LIMI

引言 小A正在balabala写代码呢,DBA小B突然发来了一条消息,"快看看你的用户特定信息表T,里面的主键,也就是自增id,都到16亿了,这才多久,在这样下去过不了多久主键就要超出范围了,插入就会失败,balabala......" 我记得没有这么多,最多1k多万,count了下,果然是1100万.原来运维是通过auto_increment那个值看的,就是说,表中有大量的删除插入操作,但是我大部分情况都是更新的,怎么会这样? 问题排查 这张表是一个简单的接口服务在使用,每天大数据会

知乎采集: MyISAM/InnoDB默认用B-Tree索引(可理解为"排好序的快速查找结构"). InnoDB中,主索引文件上直接存放该行数据,称为聚簇索引.次索引指向对主键的引用:MyISAM中,主索引和次索引,都指向物理行(磁盘位置): 注意: 对InnoDB来说1: 主键索引既存储索引值,又在叶子中存储行的数据;2: 如果没有定义主键,则会使用非空的UNIQUE键做主键 ; 如果没有非空的UNIQUE键,则系统生成一个6字节的rowid做主键; 聚簇索引中,N行形成一个页.如果

今天在使用数据库的时候,遇到一个场景,即在插入数据完成后需要返回此数据对应的自增主键id,但是在使用Mybatis中的generatedKey且确认各项配置均正确无误的情况下,每次插入成功后,返回的都是1,而不是最新的自增Id. 终于凭借着一次Debugg发现的问题,原来在使用Mabatis中的insert或者insertSelective方式插入时,如使用int insert(TestGenKey testGenKey)时,返回值int表示的是插入操作受影响的行数,而不是指的自增长id,那么返

1.从业务上来说 在设计数据库时不需要费尽心思去考虑设置哪个字段为主键.然后是这些字段只是理论上是唯一的,例如使用图书编号为主键,这个图书编号只是理论上来说是唯一的,但实践中可能会出现重复的 情况.所以还是设置一个与业务无关的自增ID作为主键,然后增加一个图书编号的唯一性约束. 2.从技术上来说 如果表使用自增主键,那么每次插入新的记录,记录就会顺序添加到当前索引节点的后续位置,当一页写满,就会自动开辟一个新的页. 总的来说就是可以提高查询和插入的性能. 对InnoDB来说 1: 主键索引既存储

数据库自增ID机制原理介绍 在分布式里面,数据库的自增ID机制的主要原理是:数据库自增ID和mysql数据库的replace_into()函数实现的.这里的replace数据库自增ID和mysql数据库的replace_into()函数实现的.这里的replace into跟insert功能类似,不同点在于:replace into首先尝试插入数据列表中,如果发现表中已经有此行数据(根据主键或唯一索引判断)则先删除,再插入.否则直接插入新数据. 单机mysql数据库的自增id实现如下所示 : 首

分库分表之后,ID 主键如何处理? 面试题 分库分表之后,id 主键如何处理? 面试官心理分析 其实这是分库分表之后你必然要面对的一个问题,就是 id 咋生成?因为要是分成多个表之后,每个表都是从 1 开始累加,那肯定不对啊,需要一个全局唯一的 id 来支持.所以这都是你实际生产环境中必须考虑的问题. 面试题剖析 基于数据库的实现方案 数据库自增 id 这个就是说你的系统里每次得到一个 id,都是往一个库的一个表里插入一条没什么业务含义的数据,然后获取一个数据库自增的一个 id.拿到这个 id

MySQL 里有很多自增的 id,每个自增 id 都是定义了初始值,然后不停地往上加步长.虽然自然数是没有上限的,但是在计算机里,只要定义了表示这个数的字节长度,那它就有上限.比如,无符号整型 (unsigned int) 是 4 个字节,上限就是 2^32-1 既然自增 id 有上限,就有可能被用完.但是,自增 id 用完了会怎么样呢? 今天这篇文章,我们就来看看 MySQL 里面的几种自增 id,一起分析一下它们的值达到上限以后,会出现什么情况. 表定义自增值 id 说到自增 id,你第一个

1.为什么数据库id自增和uuid不适合分布式id id自增:当数据量庞大时,在数据库分库分表后,数据库自增id不能满足唯一id来标识数据:因为每个表都按自己节奏自增,会造成id冲突,无法满足需求.              分库分表:分表就是把一个表的数据放到多个表中,将一个库的数据拆分到多个库中 uuid:UUID长且无序:主键应越短越好,无序会造成每一次UUID数据的插入都会对主键地城的b+树进行很大的修改   在时间上,1)uuid由于占用的内存更大,所以查询.排序速度会相对较慢:2)在

在mysql中很多朋友都认为字段为AUTO_INCREMENT类型自增ID值是无法修改,其实这样理解是错误的,下面介绍mysql自增ID的起始值修改与设置方法. 通常的设置自增字段的方法: 创建表格时添加: create table table1(id int auto_increment primary key,...) 创建表格后添加: alter table table1 add id int auto_increment primary key 自增字段 一定要设置为primary ke

set identity_insert 表名 ON --允许对自增列Id插入指定数据 insert into table_name(Id,Name) values(1,'test') set identity_insert 表名 OFF --关闭对自增列Id插入指定数据 注意: 1.set identity_insert只对当前会话生效. 2.set identity_insert 表名 ON 设置后,必须显示指定Id,否则插入错误.如insert into table_name values(

MYSQL获取自增ID的四种方法 1. select max(id) from tablename 2.SELECT LAST_INSERT_ID() 函数 LAST_INSERT_ID 是与table无关的,如果向表a插入数据后,再向表b插入数据,LAST_INSERT_ID会改变. 在多用户交替插入数据的情况下max(id)显然不能用.这时就该使用LAST_INSERT_ID了,因为LAST_INSERT_ID是基于Connection的,只要每个线程都使用独立的 Connection对象,

Twitter-Snowflake算法产生的背景相当简单,为了满足Twitter每秒上万条消息的请求,每条消息都必须分配一条唯一的id,这些id还需要一些大致的顺序(方便客户端排序),并且在分布式系统中不同机器产生的id必须不同. snowflake把时间戳,工作机器id,序列号组合在一起. 除了最高位bit标记为不可用以外,其余三组bit占位均可浮动,看具体的业务需求而定.以下关于此算法的可行性研究 Console.WriteLine() / ( * * 1000.0)); Console.W

mysql和oracle插入的时候有一个很大的区别是,oracle支持序列做id,mysql本身有一个列可以做自增长字段,mysql在插入一条数据后,如何能获得到这个自增id的值呢? 方法一是使用last_insert_id ? 1 mysql> SELECT LAST_INSERT_ID(); 产生的ID 每次连接后保存在服务器中.这意味着函数向一个给定客户端返回的值是该客户端产生对影响AUTO_INCREMENT列的最新语句第一个 AUTO_INCREMENT值的.这个值不能被其它客户端影响

回滚后,自增ID仍然增加. 比如当前ID是7,插入一条数据后,又回滚了.然后你再插入一条数据,此时插入成功,这时候你的ID不是8,而是9.因为虽然你之前插入回滚,但是ID还是自增了. 如果你认为自增ID不应该被事务化,那么其他事务不得不等待着,检查自增ID是被使用还是被回滚,这就导致阻塞.比如下面的例子,A表使用自增ID.User 1------------begin transactioninsert into A ...insert into B ...update C ...insert

有一个表StuInfo,里面只有两列 StuID,StuName其中StuID是int型,主键,自增列.现在我要插入数据,让他自动的向上增长,insert into StuInfo(StuID,StuName) values(????) 如何写? INSERT INTO StuInfo(StuID,StuName) VALUES (NULL, `字符`)或者INSERT INTO StuInfo(StuName) VALUES (`字符`) INSERT和REPLACE语句的功能都是向表中插入新

    在集群的环境中,有这种场景     需要整数自增ID,这个整数要求一直自增,并且需要保证唯一性. Web服务器集群调用这个整数生成服务,然后根据各种规则,插入指定的数据库.        一般来说,整数自增可以通过几个方式实现.    1.MySQL 单独建一个表,使用Auto_increment特性. CREATE TABLE `test` ( `id` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoD

博友们一起来讨论下高并发非自增ID如何设计? 底层是很重要的,我最近设计底层,通用底层. 我想跟大家谈论下这个话题: 如何在高并发环境下设计出一套好用的非自增ID的添加操作的解决方案?更新的操作我随机生成一个时间因子,新增的解决方案就希望大家可以一起讨论下. 打个比方,一个表,一万条新增请求同时涌进来,表为空,也就是一万条同时获取到要赋值的id就是1,更新了第一条,剩下的怎么处理?在第二条处理过程中,又有一万条新增记录涌进来,又如何处理?如何保证性能,ID不重复,友好性?ID列设计为聚集索引主键

<insert id="save" parameterType="Vote" useGeneratedKeys="true" keyProperty="id"> INSERT INTO vote VALUES(null,#{theme},#{isuse}) <selectKey resultType="int" order="AFTER" keyProperty=&qu