189 8069 5689
MYSQL的自增列在实际生产中应用的非常广泛，相信各位所在的公司or团队，MYSQL开发规范中一定会有要求尽量使用自增列去充当表的主键，为什么DBA会有这样的要求，各位在使用MYSQL自增列时遇到过哪些问题？这些问题是由什么原因造成的呢？本文由浅入深，带领大家彻底弄懂MYSQL的自增机制。
网站建设哪家好，找创新互联！专注于网页设计、网站建设、微信开发、微信小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了城关免费建站欢迎大家使用！
1. 通过auto_increment关键字来指定自增的列，并指定自增列的初始值为1。
[root@localhost][test1]Create table t(id int auto_increment ,namevarchar(10),primary key(id))auto_increment=1;
QueryOK, 0 rows affected (0.63 sec)
2. 自增列上必须有索引，将t表的主键索引删除掉，会报错
[root@localhost][test1]alter table t drop primary key;
ERROR1075 (42000): Incorrect table definition; there can be only one auto column andit must be defined as a key
3. 设定auto_increment_increment参数，可以调整自增步长，该参数有session级跟global级，在分库分表以及双主or多主的模式下比较有用。
4. 一个表上只能有一个自增列
5. Mysql5.7及以下版本，innodb表的自增值保存在内存中，重启后表的自增值会设为max(id)+1，而myisam引擎的自增值是保存在文件中，重启不会丢失。Mysql8.0开始，innodb的自增id能持久化了，重启mysql，自增ID不会丢。
首先：表中自增列的上限是根据自增列的字段类型来定的。
若设定了自增id充当主键，当达到了自增id的上限值时，会发生什么样的事情呢？还是以上面创建的 t表为例， 先回顾它的表结构：
CREATETABLE `t` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(10) COLLATE utf8mb4_binDEFAULT NULL,
PRIMARY KEY (`id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
无符号的int类型，上限是2147483647。这里我们将表的自增值设为2147483647，再插入两行数据：
[root@localhost][test1]alter table t auto_increment=2147483647;
QueryOK, 0 rows affected (0.01 sec)
Records:0 Duplicates: 0 Warnings: 0
[root@localhost][test1]insert into t(name) values ('test');
QueryOK, 1 row affected (0.01 sec)
[root@localhost][test1]insert into t(name) values ('test');
ERROR 1062 (23000): Duplicate entry '2147483647' for key 'PRIMARY'
可以看到，第一个插入没问题，因为自增列的值为2147483647，这是达到了上限，还没有超过，第二行数据插入时，则报出主键重复，在达到上限后，无法再分配新的更大的自增值，也没有从1开始从头分配，在这里表的auto_increment值会一直是2147483647。
对于写入量大，且经常删除数据的表，自增id设为int类型还是偏小的，所以我们为了避免出现自增id涨满的情况，这边统一建议自增id的类型设为unsigned bingint，这样基本可以保障表的自增id是永远够用的。
这里内容比较多，innodb是索引组织表，所以涉及到索引的知识，但这不是本文的重点，我们快速回顾索引知识：
1. Innodb索引分为主键跟辅助索引，主键即全表，辅助索引叶子节点保存主键的值，而主键的叶子节点保存数据行，中间节点存着叶子节点的路由值。
2. Innodb存储数据（索引）的单位是页，这里默认是16K，这也意味着，数据本身越小，一个页中能存数据的量越多，而检索效率不仅仅由索引的层数来决定，更是由一次能够缓存的数据量来定，也就是说数据本身越小，则一次IO能够提取到缓冲区的数据越多（OS每次IO的量是固定的4K），查询的效率越好。
其实能够理解索引的结构及索引写入插入、更新的原理，则自然就明白为何建议使用自增id。这里我直接列出使用自增id 当主键的好处吧：
1. 顺序写入，避免了叶的分裂，数据写入效率好
2. 缩小了表的体积，特别是相比于UUID当主键，甚至组合字段当主键时，效果更明显
3. 查询效率好，原因就是我上面说到索引知识的第二点。
4. 某些情况下，我们可以利用自增id来统计大表的大致行数。
5. 在数据归档or垃圾数据清理时，也可方便的利用这个id去操作，效率高。
容易出现不连续的id
有的同志会发现，自己的表中id值存在空洞，如类似于1、2、3、8、9、10这样，有的适合有想依赖于自增id的连续性来实现业务逻辑，所以会想方设法去修改id让其变的连续，其实，这是没有必要的，这一块的业务逻辑交由MySQL实现是很不理智的，表的记录小还好，要是表的数据量很大，修改起来就糟糕了。那么，为什么自增id会容易出现空洞呢？
自增id的修改机制如下：
在MySQL里面，如果字段id被定义为AUTO_INCREMENT，在插入一行数据的时候，自增值的行为如下：
1. 如果插入数据时id字段指定为0、null 或未指定值，那么就把这个表当前的
AUTO_INCREMENT值填到自增字段；
2. 如果插入数据时id字段指定了具体的值，就直接使用语句里指定的值。
根据要插入的值和当前自增值的大小关系，自增值的变更结果也会有所不同。假设，某次要插入的值是X，当前的自增值是Y。
1. 如果XY，那么这个表的自增值不变；
2. 如果X≥Y，就需要把当前自增值修改为 新的自增值 。
新的自增值生成算法是：从auto_increment_offset开始，以auto_increment_increment为步长，持续叠加，直到找到第一个大于X的值，作为新的自增值。
Insert、update、delete操作会让id不连续。
Delete、update：删除中间数据，会造成空动，而修改自增id值，也会造成空洞（这个很少）。
Insert：插入报错（唯一键冲突与事务回滚），会造成空洞，因为这时候自增id已经分配出去了，新的自增值已经生成，如下面例子：
[root@localhost][test1] select * fromt;
+----+------+
| id | name |
+----+------+
| 1| aaa |
| 2| aaa |
| 3| aaa |
| 4| aaa |
+----+------+
4 rows in set (0.00 sec)
[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';
+----------------+
| Auto_increment |
+----------------+
| 5 |
+----------------+
1 row in set (0.00 sec)
[root@localhost][test1] begin;
Query OK, 0 rows affected (0.00 sec)
[root@localhost][test1] insert intot(name) values('aaa');
Query OK, 1 row affected (0.00 sec)
[root@localhost][test1] select * fromt;
+----+------+
| id | name |
+----+------+
| 1| aaa |
| 2| aaa |
| 3| aaa |
| 4| aaa |
| 5| aaa |
+----+------+
5 rows in set (0.00 sec)
[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';
+----------------+
| Auto_increment |
+----------------+
| 6 |
+----------------+
1 row in set (0.00 sec)
[root@localhost][test1] rollback;
Query OK, 0 rows affected (0.00 sec)
[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';
+----------------+
| Auto_increment |
+----------------+
| 6 |
+----------------+
1 row in set (0.01 sec)
[root@localhost][test1] select * fromt;
+----+------+
| id | name |
+----+------+
| 1| aaa |
| 2| aaa |
| 3| aaa |
| 4| aaa |
+----+------+
4 rows in set (0.00 sec)
可以看到，虽然事务回滚了，但自增id已经回不到从前啦，唯一键冲突也是这样的，这里就不做测试了。
在批量插入时（insert select等），也存在空洞的问题。看下面实验：
[root@localhost][test1] select * fromt;
+----+------+
| id | name |
+----+------+
| 1| aaa |
| 2| aaa |
| 3| aaa |
| 4| aaa |
+----+------+
4 rows in set (0.00 sec)
[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';
+----------------+
| Auto_increment |
+----------------+
| 5 |
+----------------+
1 row in set (0.00 sec)
[root@localhost][test1] insert intot(name) select name from t;
Query OK, 4 rows affected (0.04 sec)
Records: 4 Duplicates: 0 Warnings: 0
[root@localhost][test1] select * fromt;
+----+------+
| id | name |
+----+------+
| 1| aaa |
| 2| aaa |
| 3| aaa |
| 4| aaa |
| 5| aaa |
| 6| aaa |
| 7| aaa |
| 8| aaa |
+----+------+
8 rows in set (0.00 sec)
[root@localhost][test1] selectAuto_increment from information_schema.tables where table_name='t';
+----------------+
| Auto_increment |
+----------------+
| 12 |
+----------------+
1 row in set (0.00 sec)
可以看到，批量插入，导致下一个id值不为9了，再插入数据，即产生了空洞，这里是由mysql申请自增值的机制所造成的，MySQL在批量插入时，若一个值申请一个id，效率太慢，影响了批量插入的速度，故mysql采用下面的策略批量申请id。
1. 语句执行过程中，第一次申请自增id，会分配1个；
2. 1个用完以后，这个语句第二次申请自增id，会分配2个；
3. 2个用完以后，还是这个语句，第三次申请自增id，会分配4个；
4. 依此类推，同一个语句去申请自增id，每次申请到的自增id个数都是上一次的两倍。
在对自增列进行操作时，存在着自增锁，mysql的innodb_autoinc_lock_mode参数控制着自增锁的上锁机制。该参数有0、1、2三种模式：
0：语句执行结束后释放自增锁，MySQL5.0时采用这种模式，并发度较低。
1：mysql的默认设置。普通的insert语句申请后立马释放，insert select、replace insert、load data等批量插入语句要等语句执行结束后才释放，并发读得到提升
2：所有的语句都是申请后立马释放，并发度大大提升！但是在binlog为statement格式时，主从数据会发生不一致。这一块网上有很多介绍，我不做介绍了。
在彻底了解了MYSQL的自增机制以后，在实际生产中就能灵活避坑，这里建议不要用自增id值去当表的行数，当需要对大表准确统计行数时，可以去count(*)从库，如果业务很依赖大表的准确行数，直接弄个中间表来统计，或者考虑要不要用mysql的innodb来存储数据，这个是需要自己去权衡。另外对于要求很高的写入性能，但写入量又比较大的业务，自增id的使用依然存在热点写入的问题，存在性能瓶颈，这时候可通过分库分表来解决。
传统情况
我们先回顾一下，在没有 "立刻加列" 功能时，加列操作是怎么完成的。我们也借此来熟悉一下本期的图例：
当进行 加列操作 时，所有的数据行 都必须要 增加一段数据（图中的 列 4 数据）
如上一期图解所讲，当改变数据行的长度，就需要 重建表空间（图中灰蓝的部分为发生变更的部分）
数据字典中的列定义也会被更新
以上操作的问题在于 每次加列 操作都需要重建表空间，这就需要大量 IO以及大量的时间
立刻加列
"立刻加列" 的过程如下图：
请点击输入图片描述
请点击输入图片描述
"立刻加列" 时，只会变更数据字典中的内容，包括：
在列定义中增加 新列的定义
增加 新列的默认值
"立刻加列" 后，当要读取表中的数据时：
由于 "立刻加列" 没有 变更行数据，读取的行数据只有 3 列
MySQL 会将 新增的第 4 列的默认值，追加到 读取的数据后
以上过程描述了 如何读取 在 "立刻加列" 之前写入的数据，其实质是：在读取数据的过程中，"伪造" 了一个新列出来
那么如何读取 在 "立刻加列" 之后 写入的数据呢 ? 过程如下图：
当读取 行 4 时：
请点击输入图片描述
请点击输入图片描述
通过判断 数据行的头信息中的instant 标志位，可以知道该行的格式是 "新格式"：该行头信息后有一个新字段 "列数"
通过读取 数据行的 "列数" 字段，可以知道 该行数据中多少列有 "真实" 的数据，从而按列数读取数据
通过上图可以看到：读取 在"立刻加列" 前/后写入的数据是不同的流程
通过以上的讨论，我们可以总结 "立刻加列" 之所以高效的原因是：
在执行 "立刻加列" 时，不变更数据行的结构
读取 "旧" 数据时，"伪造" 新增的列，使结果正确
写入 "新" 数据时，使用了新的数据格式（增加了instant标志位 和 "列数" 字段)，以区分新旧数据
读取 "新" 数据时，可以如实读取数据
那么 我们是否能一直 "伪造" 下去 ? "伪造" 何时会被拆穿 ?
考虑以下场景：
用 "立刻加列" 增加列 A
写入数据行 1
用 "立刻加列" 增加列 B
写入数据行 2
删除列 B
我们推测一下 "删除列 B" 的最小代价：需要修改 数据行中的instant标志位或 "列数" 字段，这至少会影响到 "立刻加列" 之后写入的数据行，成本类似于重建数据
从以上推测可知：当出现 与 "立刻加列" 操作不兼容 的 DDL 操作时，数据表需要进行重建，如下图所示：
请点击输入图片描述
请点击输入图片描述
扩展思考题：是否能设计其他的数据格式，取代instant标志位和 "列数" 字段，使得 加列/删列 操作都能 "立刻完成" ?（提示：考虑 加列 - 删列 - 再加列 的情况）
使用限制
在了解原理之后，我们来看看 "立刻加列" 的使用限制，就很容易能理解其中的前两项：
"立刻加列" 的加列位置只能在表的最后，而不能加在其他列之间
在元数据中，只记录了 数据行 应有多少列，而没有记录 这些列 应出现的位置。所以无法实现指定列的位置
"立刻加列" 不能添加主键列
加列 不能涉及聚簇索引的变更，否则就变成了 "重建" 操作，不是 "立刻" 完成了
"立刻加列"不支持压缩的表格式
按照 WL 的说法："COMPRESSED is no need to supported"（没必要支持不怎么用的格式）
总结回顾
我们总结一下上面的讨论：
"立刻加列" 之所以高效的原因是：
在执行 "立刻加列" 时，不变更数据行的结构
读取 "旧" 数据时，"伪造" 新增的列，使结果正确
写入 "新" 数据时，使用了新的数据格式 (增加了 instant 标志位 和 "列数" 字段)，以区分新旧数据
读取 "新" 数据时，可以如实读取数据
"立刻加列" 的 "伪造" 手法，不能一直维持下去。当发生 与 "立刻加列" 操作不兼容 的 DDL 时，表数据就会发生重建
回到之前遗留的两个问题：
"立刻加列" 是如何工作的 ?
我们已经解答了这个问题
所谓 "立刻加列" 是否完全不影响业务，是否是真正的 "立刻" 完成 ?
可以看到：就算是 "立刻加列"，也需要变更 数据字典，那么 该上的锁还是逃不掉的。也就是说 这里的 "立刻" 指的是 "不变更数据行的结构"，而并非指 "零成本地完成任务"
你是想改表结构还是插入数据？\x0d\x0a表结构：右键点中表，选设计表，移动到最底部一条，“创建栏位”将在这之后增加一列；“插入栏位”将在这列之前增加一列。\x0d\x0a插入数据：双击打开表，下面有个“+”的符号，点一下，增加一条记录，然后再点一下下面的对钩保存数据。\x0d\x0anavicat 很简单的。慢慢熟悉吧，记得去把它汉化哦。