解决mysql的int型主键自增问题
引入
我们在使用mysql数据库时，习惯使用int型作为主键，并设置为自增，这既能够保证唯一，使用起来又很方便，但int型的长度是有限的，如果超过长度怎么办呢？
暴露问题
我们先创建一个测试表，创建语句如下：
CREATE TABLE test1 ( id INT PRIMARY KEY AUTO_INCREMENT, NAME VARCHAR(20) )
然后我们插入两条数据：
INSERT INTO test1 VALUES(NULL,'小牛'); INSERT INTO test1 VALUES(NULL,'大牛');
查询表显示正常：
int型的有符号的范围为231 -1 = 2147483647，我们直接插入一条数据id为2147483647，如下：
INSERT INTO test1 VALUES(2147483647 ,'小华')
结果显示正常：
此时自增ID已达到了int型的上限，如果我再插入数据，就会报错：
INSERT INTO test1 VALUES(NULL,'母牛');
此时主键已无法自增，插入的id仍然是2147483647，就违反了主键唯一的条件，所以报错。
解决问题
（1）使用更大的数据类型bigint
bigint的范围是263-1，所谓指数爆炸，此时的大小达到了9,223,372,036,854,775,807的可怕量级，简单来说就是用bigint 一天100w条数据也得存200亿年才能自增爆炸，所以在当前场景，几乎不用担心bigint会自增满
我们修改数据类型为bigint，如图
再执行插入语句：
INSERT INTO test1 VALUES(NULL,'母牛');
又能够正常插入了：
（2）使用UUID作为主键
我们都知道，UUID会根据当前系统性能，时间戳等一系列参数经过运算得到一个全世界唯一的字符串，并且mysql提供了生成UUID的方法，用它作为主键能够保证数据的唯一性。
利用如下代码可以生成32位的UUID：
-- 生成32位UUID SELECT REPLACE(UUID(),'-','') AS UUID;
然后咱们再创建一个测试表：
CREATE TABLE test2( id VARCHAR(50) PRIMARY KEY, NAME VARCHAR(20) NOT NULL )
插入一条数据：
-- 插入UUID INSERT INTO test2 VALUES(REPLACE(UUID(),'-',''),'老王');
但这样写插入语句每次都要手写UUID函数，貌似有点太麻烦了，咱们可以写一个触发器，让触发器自动为我们设置ID：
-- 创建触发器 DELIMITER $$ CREATE TRIGGER auto_id -- 名称 BEFORE INSERT -- 触发时机 ON test2 FOR EACH ROW -- 作用于test2表，对每行数据生效 BEGIN IF new.id = '' THEN -- 当id为空字符串时设置UUID SET new.id = REPLACE(UUID(),'-',''); END IF; END$$
插入一条数据：
-- 插入一条数据
INSERT INTO test2 VALUES('','小王');
结果能正常添加
总结
(1) 用int型和bigInt型增删改查速度较UUID更快，并且更节省空间。
(2) 用UUID更方便。
为何要使用自增int作为主键
相信大家都知道要使用无符号自增int作为主键的数据类型，可你知道为何要使自用增int而不是使用varchar、text、varchar等类型吗？
大家也能说出一些优点：对上层业务透明，插入数据时无需显示指定；数据类型简单，更便于存储维护表结构
其实，使用自增int作为主键好处多多，今天我们就来一起学习一下，并强烈建议大家在实际开发中使用自增int作为主键。
优点：
1、int 相比varchar、char、text使用更少的存储空间，而且数据类型简单，可以节约CPU的开销，更便于表结构的维护
2、默认都会在主键上建立主键索引，使用整形作为主键可以将更多的索引载入内存，提高查询性能
3、对于InnoDB存储引擎而言，每个二级索引都会使用主键作为索引值的后缀，使用自增主键可以减少索引的长度（大小），方便更多的索引数据载入内存
4、可以使索引数据更加紧凑，在数据插入、删除、更新时可以做到索引数据尽可能少的移动、分裂页，减少碎片的产生（可以通过optimize table 来重建表），减少维护开销
5、在数据插入时，可以保证逻辑相邻的元素物理也相邻，便于范围查找
当然，使用自增int作为主键也不是百利无一害，在高并发的情况下也可能会造成锁的争用问题。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持我们。
相关推荐
-
MySQL的自增ID(主键) 用完了的解决方法
在 MySQL 中用很多类型的自增 ID,每个自增 ID 都设置了初始值.一般情况下初始值都是从 0 开始,然后按照一定的步长增加(一般是自增 1).一般情况下,我们都是用int(11)来作为数据表的自增 ID,在 MySQL 中只要定义了这个数的字节长度,那么就会有上限. MySQL的自增ID(主键) 用完了,怎么办? 如果用 int unsigned (int,4个字节 ), 我们可以算下最大当前声明的自增ID最大是多少,由于这里定义的是 int unsigned,所以最大可以达到2的32幂
-
关于MySQL自增ID的一些小问题总结
下面这几个小问题都是基于 InnoDB 存储引擎的. 1. ID最大的记录删除后,新插入的记录ID是什么 例如当前表中有ID为1,2,3三条记录,把3删除,新插入记录的ID从哪儿开始? 答案: 从4开始. 实验 创建表 tb0,ID自增: create table tb0(id int unsigned auto_increment primary key); 插入3条记录: insert into tb0 values(null); 删除ID为3的记录: delete from tb0 whe
-
mysql自增id超大问题的排查与解决
引言 小A正在balabala写代码呢,DBA小B突然发来了一条消息,"快看看你的用户特定信息表T,里面的主键,也就是自增id,都到16亿了,这才多久,在这样下去过不了多久主键就要超出范围了,插入就会失败,balabala......" 我记得没有这么多,最多1k多万,count了下,果然是1100万.原来运维是通过auto_increment那个值看的,就是说,表中有大量的删除插入操作,但是我大部分情况都是更新的,怎么会这样? 下面话不多说了,来一起看看详细的介绍吧 问题排查 这张表
-
MySQL数字类型自增的坑
在进行表结构设计时,数字类型是最为常见的类型之一,但要用好数字类型并不如想象得那么简单,比如: 怎么设计一个互联网海量并发业务的自增主键?用 INT 就够了? 怎么设计账户的余额?用 DECIMAL 类型就万无一失了吗? 以上全错! 数字类型看似简单,但在表结构架构设计中很容易出现上述"设计上思考不全面"的问题(特别是在海量并发的互联网场景下) 数字类型 整数类型 MySQL 数据库支持 SQL 标准支持的整型类型:INT.SMALLINT.此外,MySQL 数据库也支持诸如 TINY
-
mysql自增ID起始值修改方法
在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 自
-
解决mysql的int型主键自增问题
引入 我们在使用mysql数据库时,习惯使用int型作为主键,并设置为自增,这既能够保证唯一,使用起来又很方便,但int型的长度是有限的,如果超过长度怎么办呢? 暴露问题 我们先创建一个测试表,创建语句如下: CREATE TABLE test1 ( id INT PRIMARY KEY AUTO_INCREMENT, NAME VARCHAR(20) ) 然后我们插入两条数据: INSERT INTO test1 VALUES(NULL,'小牛'); INSERT INTO test1 VAL
-
MySQL主键自增会遇到的坑及解决方法
目录 1. 为什么不用 UUID 2. 主键自增的问题 2.1 数据插入的三种形式 2.2 innodb_autoinc_lock_mode 2.3 实践 3. 小结 在上篇文章中,松哥和小伙伴们分享了 MySQL 的聚簇索引,也顺便和小伙伴们分析了为什么在 MySQL 中主键不应该使用随机字符串.但是主键不用随机字符串用什么?主键自增?主键自增就是最佳方案吗?有没有其他坑?今天我们就来讨论下这个话题. 1. 为什么不用 UUID 经过上篇文章的介绍,我们知道在 MySQL 中,主键索引就是聚簇
-
MySQL中的主键自增机制详情
目录 主键自增 自增主键保存在哪里 自增值修改机制 自增值的修改时机 如何修改自增主键值 主键自增 MySQL 提供了主键自增机制 AUTO_INCREMENT. 对主键使用, 保证了主键的唯一性. 注意:自增长必须与主键字段配合使用. 默认的主键的起始值为 1, 每次增量为 1, 也可以手动指定其自增起始值 auto_increment_offset 和自增步长 auto_increment_increment. -- 设置主键自增 CREATE TABLE USER( id INT UNSI
-
解决Mybatis查询方法selectById()主键不一致问题
Mybatis-plus的通用mapper为我们封装了很多方法,我们只需要将interface集成BaseMapper就可以.在BaseMapper中分装了一个方法=>selectById() selectById 这个方法是根据主键id进行查询记录的.返回一条记录.测试如下, 最终调用的是这个方法userDiamondMapper这个接口集成了BaseMapper. 注意这个表的主键就是uid,查询试试 返回结果不如我们预期,打印出的SQL很奇怪,并没有解析正确.猜测是因为无法正确解析出主键.
-
MySQL语句中的主键和外键使用说明
目录 一.主键: 1.1)主键字段定义: 1.2) 创建: 1.3)主键的选取原则: 1.4)主键值的生成方式: 二.外键: 2.1)外键定义: 2.2)外键(约束)创建(不推荐使用,一般不进行外键约束,只进行外键约定): 2.3)外键出现的情况: 三.主键和外键的区别总结: 一.主键: 1.1)主键字段定义: 在数据库表中,如果有一组字段能够唯一确定一条记录,则可以把它们设计成表的主键字段. 例子:如果要创建一个人的信息表(字段:姓名,年龄,籍贯,工作单位......),那么身份证号是唯一能确
-
Mysql分析设计表主键为何不用uuid
目录 一.mysql和程序实例 1.1 建表 1.2 测试 1.3 程序写入结果 1.4 效率测试结果 二.使用uuid和自增id的索引结构对比 2.1 使用自增id的内部结构 2.2 使用uuid的索引内部结构 2.3 使用自增id的缺点 三.总结 一.mysql和程序实例 1.1 建表 要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变.
-
Springboot+MybatisPlus+Oracle实现主键自增的示例代码
上周周一,本来刚过完周末,高高兴兴,老大突然安排了个活,要在一天内把项目的MySQL数据库换成Oracle数据库,我们都知道这是不可能完成的任务,但是,秉承着"没有困难的工作,只有不努力的打工人"的精神,我们马上投入了工作,第一步当然是先配置数据库.oracle建表,这个解决调试了一上午,然后下午卡到oracle主键了,所有人网上找方法,一直到第二天凌晨3点半都还没解决,网上方法很多,试了好多都不管用,终于第二天才找到了满足的方法. 废话不多说,下面贴出. application.ym
-
基于django 的orm中非主键自增的实现方式
我们知道django的orm想实现自增,可以直接使用AutoField字段既可以实现,但是这种情况必须要求此字段是主键,但是我们知道主键只能是一个. 如果我已经有了一个主键,但是又需要另外一个字段为唯一自增字段,这该如何实现呢? 本人的解决办法如下,供大家参考,也欢迎大家提供更多的实现方式,互相学习. class ProductSpu(models.Model): """ 商品表 """ _database = 'payment' id = mo
-
django自定义非主键自增字段类型详解(auto increment field)
1.django自定义字段类型,实现非主键字段的自增 # -*- encoding: utf-8 -*- from django.db.models.fields import Field, IntegerField from django.core import checks, exceptions from django.utils.translation import ugettext_lazy as _ class AutoIncreField(Field): description =
-
Mybatis-plus实现主键自增和自动注入时间的示例代码
mybatis-plus依赖导入 <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.3.2</version> </dependency> 建议使用3.3.0后的版本. 导入mybatis-plus就不用导入mybatis了,冲突! 连接数据库 sp