点击上方"码之初"关注，···选择"设为星标"
与精品技术文章不期而遇
在之前有篇文章中，和大家探讨了在MySOL数据库中，一个表的自增id用完，再插入数据有什么问题？评论处 @背井 公众号的大佬建议我另开一篇再说一下表的自增id在用完的情况下，用replace into、insert ignore以及insert... on duplicate会发生什么，当时不假思索就回复了安排，结果这一拖就快一个月了。
先创建一个简单的表，只包含一个自增字段id，像这样，勾选上自动递增和无符号
unsigned
首先，勾选上左侧的无符号才会出现unsigned类型。那unsigned是什么意思呢？整型的每一种都有无符号(unsigned)和有符号(signed)两种类型，在默认情况下声明的整型变量都是有符号的类型(char有点特别)。由于在计算机中,整数是以补码形式存放的。根据最高位的不同，如果是1,有符号数的话就是负数；如果是无符号数,则都解释为正数。同时在相同位数的情况下,所能表达的整数范围变大。另外，unsigned若省略后一个关键字，大多数编译器都会认为是unsigned int。有没有不知所云或者不明觉厉，简单点解释就是，在mysql中创建表时，如果整型使用了unsigned类型，那么该数据项就永远是正整数，每种数值类型的名称和取值范围如下表所示：
下面通过sql实例演示一下，我们先去掉勾选无符号，建表语句变成
这时候已经没有unsigned了，我们向表里插入两条数据，一条正数一条负数：
INSERT INTO t VALUES (1);INSERT INTO t VALUES (-1);结果显示插入成功
表里也有数据：
接下来我们修改表结构，勾选上无符号使用unsigned类型，像最初那样
这时候我们再向表里插入两条数据，一条正数一条负数：
INSERT INTO t VALUES (1);INSERT INTO t VALUES (-1);看看执行结果：
姿势一：insert into
我们先直接暴力输出，在创建表的时候，直接将AUTO_INCREMENT的初始值声明为4294967295，sql如下：
CREATE TABLE `t` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=4294967295 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;然后我们友好的向表中插一条数据：
INSERT INTO t VALUES (NULL);
咦，成功了，什么情况，我们打开表看看：
这是什么鬼？我不是插入的null吗？
先解释第一个疑问，废话，当然能插进去了，因为AUTO_INCREMENT=4294967295是从这个开始，当然还能插进去，为什么插入null变成了4294967295，因为只有一个字段，插入的null又不是id的值，id是自增主键啊，现在明白了吧，有可能有人觉得我这两个问题好无聊，但是我真的见过有不少人不知道，不信你以后面试时可以随机问问。高潮来了，我们这时候再插入一条数据呢，还能插进去吗？走起：
INSERT INTO t VALUES (NULL);看结果，oh no，报主键冲突了：
REPLACE INTO t VALUES (NULL);可以发现和之前报一样的错，都是主键冲突。
那么，是不是insert into和replace into这两条sql在自增id用完这种情况下，继续插入数据时发生了一样的遭遇呢？
我们下来看一下自增id未满的情况下，这两条sql是怎样执行的。
1、新建一张表，自增id就从1开始(默认也是从1)
DROP TABLE IF EXISTS t1;CREATE TABLE `t1` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`num` int(10) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;2、先使用insert into插入一条数据：
INSERT INTO t1 VALUES (1,1);查看结果：
看一下表结果：
3、再使用replace into：
REPLACE INTO t1 VALUES (1,1);查看结果：
看一下表结果：
4、再使用replace into：
REPLACE INTO t1 VALUES (1,2);查看执行结果：
再看一下表结果：
划重点来了：
replace into 跟 insert 功能类似，不同点在于：replace into 首先尝试插入数据到表中，这时候：
如果发现表中已经有此行数据(根据主键或者唯一索引判断)则先删除此行数据，然后插入新的数据。
否则，直接插入新数据。
insert into ignore就比较简单了，我们直接运行sql看结果：
insert ignore into t VALUES (NULL);结果显示：
可以看到受影响的行为0，这就是insert ignore 的作用：
如果发现表中已经有此行数据(根据主键或者唯一索引判断)则跳过此查询，不对数据库作任何操作;
否则没有此行数据的话，直接插入新数据。
姿势四：insert ...on duplicate
老样子，我们先通过sql实例看看自增id最大时，使用insert... on duplicate key会发生什么，sql运行起来：
INSERT INTO t VALUES (NULL) ON DUPLICATE KEY UPDATE id =id+1;查看运行结果：
依旧是主键冲突错误。
下面我们来简单分析一下INSERT ON DUPLICATE KEY UPDATE这条sql做了什么事。我们在日常业务开发中经常有这样一个场景，首先创建一条记录，然后插入到数据库；如果数据库已经存在同一主键的记录，则执行update操作，如果不存在，则执行insert操作，这个时候INSERT ON DUPLICATE KEY UPDATE就派上用场了。在MySQL数据库中，如果在insert语句后面带上ON DUPLICATE KEY UPDATE 子句，而要插入的行与表中现有记录的惟一索引或主键中产生重复值，那么就会发生旧行的更新；如果插入的行数据与现有表中记录的唯一索引或者主键不重复，则执行新纪录插入操作。另外，ON DUPLICATE KEY UPDATE不能写where条件。以上就是当Mysql的一张表自增id用完了，此时再以各种姿势向表里插入数据会发生什么的一些实践探讨，同时也加了其他一些知识点的讲解，感谢尤慕大佬的建议，让我在漫漫路上多了一些求索的动力。知识拓展
如果在创建表时没有显示声明主键，会怎么办呢？如果是这种情况，InnoDB会自动帮你创建一个不可见的、长度为6字节的row_id，而且InnoDB 维护了一个全局的 dictsys.row_id，所以未定义主键的表都共享该row_id，每次插入一条数据，都把全局row_id当成主键id，然后全局row_id加1，该全局row_id在代码实现上使用的是bigint unsigned类型，但实际上只给row_id留了6字节，这种设计就会存在一个问题：如果全局row_id一直涨，一直涨，直到2的48幂次-1时，这个时候再+1，row_id的低48位都为0，结果在插入新一行数据时，拿到的row_id就为0，存在主键冲突的可能性。所以，为了避免这种隐患，每个表都需要定一个主键。最后，留下一个问题，大家知道int(0)和int(10)有什么区别吗？
好文，点个在看吧
)
