- 综合排序
- 最热优先
- 最新优先
- 来自专栏数据库
MySQL自增锁的探究
2.5 自增锁 MySQL的自增锁是指在使用自增主键（Auto Increment）时，为了保证唯一性和正确性，系统会对自增字段进行加锁。 ); 特点：为一些(但不是全部)新行指定自动增量值 2.5.2 自增锁原理 1）插入原理 MySQL自增锁的实现机制是使用了一个名为"auto-increment lock"的互斥锁。 当使用INSERT语句插入一条新记录时，MySQL会自动为自增字段加锁，防止其他并发的插入操作同时获取相同的自增值。这个锁是在内部实现的，不需要用户手动创建或管理。 Tips：自增锁跟事务无关，即使多个insert语句存在同一个事务中，每次insert都会申请最新的自增锁来获取最新的AUTO_INCREMENT值；获取到自增值后释放，而不是事务结束释放； 2）自增锁表锁 这也是InnoDB的默认值； Simple inserts：InnoDB能够预先知道要插入的行数，因此产生的自增锁只会锁住对应的那些id（页锁），避免表级别的自增锁 Bulk Inserts：InnoDB
1.1K96编辑于 2025-01-03 - 来自专栏Java后端技术栈cwnait
浅谈MySQL自增锁
select last_insert_id(); 五、自增锁 如果存在自增字段，MySQL会维护一个自增锁，和自增锁相关的一个参数为（5.1.22版本之后加入） innodb_autoinc_lock_mode 但是Innodb会视参数不通二产生不通的锁。目前MySQL默认的配置为1。 六、自增的过程 第一种，插入空值的时候 当innodb_autoinc_lock_mode=0时 1、申请AUTO_INC锁 2、得到当前的AUTO_INCREMENT值n，并加1 3、执行插入操作 为了保证主库和从库的自增ID的一致性，binlog中会有set insert_ID命令，标明这个load语句的第一行的自增ID值，这样在表锁的情况下，就可以保证一致性了。 自增锁分享就到这里了。
6.2K30发布于 2020-04-14 - 来自专栏csico
深入剖析 MySQL 自增锁
之前的文章把 InnoDB 中的所有的锁都介绍了一下，包括意向锁、记录锁...自增锁巴拉巴拉的。但是后面我自己回过头去看的时候发现，对自增锁的介绍居然才短短的一段。 其实自增锁（AUTO-INC Locks）这块还是有很多值得讨论的细节，例如在并发的场景下，InnoDB 是如何保证该值正确的进行自增的，本章就专门来简单讨论一下 InnoDB 中的自增锁。 什么是自增锁 之前我们提到过，自增锁是一种比较特殊的表级锁。 行为与限制 其实上面说的那种阻塞情况只是自增锁行为的其中一种，可以理解为自增锁就是一个接口，其具体的实现有多种。 基于 MySQL 默认 Binlog 格式从 Statement 到 Row 的变更，InnoDB 也将其自增锁的默认实现从连续模式，更换到了效率更高的交叉模式。
4.1K40发布于 2021-10-08 - 来自专栏SH的全栈笔记
深入剖析 MySQL 自增锁
但是后面我自己回过头去看的时候发现，对自增锁的介绍居然才短短的一段。 其实自增锁（AUTO-INC Locks）这块还是有很多值得讨论的细节，例如在并发的场景下，InnoDB 是如何保证该值正确的进行自增的，本章就专门来简单讨论一下 InnoDB 中的自增锁。 什么是自增锁 之前我们提到过，自增锁是一种比较特殊的表级锁。 行为与限制 其实上面说的那种阻塞情况只是自增锁行为的其中一种，可以理解为自增锁就是一个接口，其具体的实现有多种。 基于 MySQL 默认 Binlog 格式从 Statement 到 Row 的变更，InnoDB 也将其自增锁的默认实现从连续模式，更换到了效率更高的交叉模式。
3.7K20编辑于 2022-08-17 - 来自专栏全栈程序员必看
mysql 主键自增语句_MySQL 自增主键
连续性 插入成功时，其数据的 ID 和前一次插入成功时数据的 ID 相邻。 自增主键的单调性 为何会有单调性的问题？ 这主要跟自增主键最大值的获取方式，以及存放位置有关系。 MySQL 5.7 及之前的版本，自增主键最大值会在启动(重启)后从数据库中取出放到内存： SELECT MAX(ai_col) FROM table_name FOR UPDATE; 这样获取是通过计算的 从 MySQL 8.0 开始，自增主键最大值会在每次修改后写入到 redo log，并且在每个检查点写入引擎私有的系统表。 如果是正常重启，则读取系统表里的值。 之所以事务 A 没提交的情况下，事务 B 就能执行插入语句，跟 InnoDB 的自增长锁(AUTO-INC Locking)相关。 参考文档 为什么 MySQL 的自增主键不单调也不连续 https://database.51cto.com/art/202004/614923.htm 《MySQL技术内幕——InnoDB存储引擎》
14.6K10编辑于 2022-07-18 - 来自专栏全栈程序员必看
mysql主键自增策略_MySQL 自增主键机制
不同的存储引擎保存自增值的策略不一样； a. 对于MyISAM引擎，自增值保存在数据文件中； b. Innodb引擎，mysql5.7之前，自增值保存在内存中，而且不会持久化自增值。 自增值修改发生在插入数据的操作之前，如果插入失败，自增值不会再修改回去； b. 事务回滚也不会将自增值修改回去； c. 为了减少自增id锁带来的性能影响，mysql不会修改回去之前的自增值； 4. 自增锁的优化 a. 自增锁不是事务锁，在每次申请完就释放；在5.0版本会在语句执行完才释放，后续版本无须在语句执行完才释放；支持批量申请； b. 一次性insert多条记录时，如果能计算出需要多少个id，就一次性申请，申请完就释放； c. insert … select 默认会使用语句级的锁，只有语句执行完才会释放自增锁，为了数据的一致性； d. 而对于批量插入数据的语句(select … insert，replace … select 和 load data 语句)，MySQL 有一个批量申请自增 id 的策略(注：该策略是导致自增 id 不连续的第三种原因
12.7K50编辑于 2022-09-07 - 来自专栏DBA随笔
Innodb锁机制探究(一)---自增锁(2)
今天就补充一点之前遗漏的内容吧。 // Innodb锁机制探究(一)---自增锁(2) // 之前我们说过一篇关于MySQL的自增锁，但是没有系统的做测试，今天做一点测试，看看效果。 innodb锁机制探究(一)---自增锁(1) 当我们进行插入操作的时候，该操作会根据这个自增长的计数器的值+1赋予自增长的列，这个操作我们称之为auto-inc Locking，也就是自增长锁，这种锁其实采用的是特殊的表锁机制 来看我们的测试过程，为了理解方便，我们首先创建一个表，然后查看相关的参数： mysql:yeyztest ::>>show create table lock_test1\G ************* 翻译过来就是：自增锁是一种特殊的表级别锁（table-level lock），专门针对事务插入AUTO_INCREMENT类型的列。 2、对于常规的insert操作，可以使用参数innodb_autoinc_lock_mode来控制是否使用表级别的锁，如果该参数是0，则使用表级别的auto_inc 锁，如果该参数是1，则使用互斥自增长机制实现主键的自增
1.8K20发布于 2019-11-19 - 来自专栏开源部署
关于 MySQL 的自增字段
因为MySQL中的自增字段与Oracle数据库是不一样的，所以在这里记录一下MySQL的自增字段。 table definition; there can be only one auto column and it must be defined as a key 0.000 sec 2.设置自增的起始值 在mysql中自增字段的起始自增值为1，但有时候我们并不是要求从1开始自增，这时需要我们的手动设置。 alter table emp auto_increment=100; 注意：在创建表后再设置自增值的情况下，如果在设置之前就已经插入了数据的话，然后再插入数据，在数据库中的数据是不会改变的，但是这样操作会造成数据插不进去的情况 ，因为插入的自增主键有可能与之前的值相同。
4.6K20编辑于 2022-08-18 - 来自专栏全栈开发那些事
mysql自增主键设置
mysql自增主键设置 在数据库应用中，经常希望在每次插入新纪录时，系统自动生成字段的主键值。可以通过为表主键添加AUTO_INCREMENT关键字来实现。 默认情况下，在MYSQL中AUTO_INCREMENT的初始值是1，每新增一条记录，字段值自动加1.一个表只能有一个字段属用AUTO_INCREMENT约束，且该字段必须为主键的一部分。 AUTO_INCREMENT约束的字段可以是任何整数类型(TINTINT、SMALLINT、INT、BIGINT等) 设置表的属性值自动增加的语法规则如下: 字段名 数据类型 AUTO_INCREMENT insert into tb_emp8(name,salary) values('lucy',1000),('lura',1200),('kevin',1500); 查看数据表 在这里并没有输入id的值
14.2K30编辑于 2023-02-25 - 来自专栏信息安全小学生
【Mysql】自增相关配置
创建表时设置 设置表 SOME_TABLE 自增起点为 101。 CREATE TABLE `SOME_TABLE` (ID INT PRIMARY KEY AUTO_INCREMENT) AUTO_INCREMENT=101; 随时设置 设置表 SOME_TABLE 自增起点为 ALTER TABLE `SOME_TABLE` AUTO_INCREMENT=101; 全局设置自增的间隔 针对所有表，每次自增从 += 1 变成 += 3。 mysql> SET AUTO_INCREMENT_INCREMENT=3; 全局设置自增的起点 针对所有表，默认自增起点为 101。 mysql> SET AUTO_INCREMENT_OFFSET=101;
4.7K20发布于 2021-08-25 - 来自专栏快乐阿超
mysql重置自增主键坑
商人的兴趣就在那些能找到财富的地方。 ——埃伯克 今天重置mysql自增主键时遇到个坑，明明sql执行了 ALTER TABLE table_name AUTO_INCREMENT= 1; 但还是修改失败了 后来发现原来是因为当前表最大 id比我设置的自增id大导致的 而且这种情况还不报错，提示sql正常执行，就挺坑的 最后把表内数据调整了，成功重置自增id 可以通过 SHOW TABLE STATUS WHERE NAME = 'user
8.3K10编辑于 2022-08-17 - 来自专栏DBA随笔
MySQL replace into导致的自增id问题
// MySQL replace into导致的自增id问题 // 今天线上遇到一个问题，挺有意思，这里记录一下希望对大家有所帮助。 某个表中，只有一条记录，发生高可用切换之后，自增id的值发生了变化，主从的自增id值不一致，导致数据写入报主键冲突的错误。 此时如果主从库发生切换，那么新插入到从库中的id=6的值就会发生主键冲突了，显示插入不进去，这是我们不想看到的。 那么为什么从库上的自增值和主库不一致呢？ */; 可以看到，MySQL将replace into的在binlog中保存的格式是update语句，那么update语句本质上不会对自增值进行修改，所以就导致了主从的表自增id不一致，这样虽然看着没有什么问题 ，从库的自增id比主库的小，当主从发生切换的时候，这个问题就比较严重了，有些数据写入的时候，就会报错了。
8.6K20发布于 2020-07-28 解决MySQL自增id用尽的问题
背景介绍我们项目中有一张article_click_record表，用户每次点进一篇文章，就会往该表中插入一条记录article_click_record表主要有如下三列：id：自增主键，INT类型user_id 解决方案首先，对于表的自增id即将溢出的问题，由于该表存在大量记录，因此不能直接将该表的id列改为BIGINT类型我们实际采用的解决id溢出的方式是：新增一张article_click_record_new id溢出后，新表的数据也就预热完成了，此时只往新表中写入数据，并且在读表时，也可以直接读取新表了 新表的id列采用BIGINT类型的原因： 避免再次出现自增id用尽的问题由于业务需要，我们希望id是保持递增的 return record.getId(); } // 否则，尝试往旧表中插入数据 // 如果主键重复，说明id已经溢出（MySQL 在自增id达到最大值后，下次再获取自增id时，还是会获取到最大值） // 因此，当出现DuplicateKeyException异常时，只需将oldTableIdOverflow设置为true
1.7K10编辑于 2025-03-25- 来自专栏性能与架构
MySQL 自增ID的几个小问题
ID为4，删除ID最大的记录并不影响自增ID的值。 MySQL 重启后自增ID从哪儿开始 例如当前表中有ID为1,2,3三条记录，把3删除，重启MySQL，新插入记录的ID从哪儿开始？ 很多人会认为从4开始，实际是从3开始。 重启MySQL。 手动插入ID后，下次插入时自增值是多少 例如当前的自增ID为4，新插入记录时，手动指定ID为10，下次使用自增方式插入时，ID是 11。 删除最大ID值对自增ID值没有影响，但MySQL重启之后有影响，不会使用之前的自增ID值，而是使用最大ID+1，因为自增ID值是存在内存中，重启后需要重新计算。 自增ID用完后就不变了。
8.9K21发布于 2019-11-19 - 来自专栏全栈程序员必看
MySQL自增主键值回溯问题
大家好，又见面了，我是你们的朋友全栈君。 平时我们使用MySQL时，通常每一个表都会有一个自增主键ID，每新增一条数据，ID值就会自增1。 但在8.0之前版本的MySQL中，这个自增值会存在一个回溯的问题。 然后把ID=3的数据行删掉，再次查询AUTO_INCREMENT的值，依然是4，这也是没问题的。 但如果重启一下MySQL，这个值就会变回3，而不是4，发生了回溯。 这是因为AUTO_INCREMENT的值只存储于内存中，不会持久化到磁盘，每次启动数据库时，MySQL会通过计算max(auto_increment字段) + 1，重新作为该表下一次的主键ID的自增值。 这个问题直至MySQL 8.0才修复。 发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/149188.html原文链接：https://javaforall.cn
5.3K20编辑于 2022-07-04 - 来自专栏玩转JavaEE
MySQL 主键自增注意事项
很多小伙伴应该知道，在 MySQL 中主键不应该使用随机字符串。但是主键不用随机字符串用什么？主键自增？主键自增就是最佳方案吗？有没有其他坑？今天我们就来讨论下这个话题。 1. 基于上面的分析，我们在 MySQL 中尽量不使用 UUID 作为主键，不用 UUID，可能会有小伙伴想到，那我使用主键自增行不行？ 将数据插入分为这三类，主要是因为在主键自增的时候，锁的处理方案不同，我们继续往下看。 2.2 innodb_autoinc_lock_mode 我们可以通过控制 innodb_autoinc_lock_mode 变量的值，来控制在主键自增的时候，MySQL 锁的处理思路。 SQL 语句开始的时候，获取到一个表级的 AUTO-INC 锁，然后当插入 SQL 执行完毕之后，再释放掉这把锁，这样做的好处是可以确保在批量插入的时候，自增主键是连续的。
2K10编辑于 2024-06-07 - 来自专栏全栈程序员必看
MySQL自增主键详解「建议收藏」
出现了自增主键不连续的情况 唯一键冲突和事务回滚都会导致自增主键id不连续的情况 四、自增锁的优化 自增id锁并不是一个事务锁，而是每次申请完就马上释放，以便允许别的事务再申请 但在MySQL5.0版本的时候 ，自增锁的范围是语句级别。 也就是说，如果一个语句申请了一个表自增锁，这个锁会等语句执行结束以后才释放 MySQL5.1.22版本引入了一个新策略，新增参数innodb_autoinc_lock_mode，默认值是1 1.这个参数设置为 0，表示采用之前MySQL5.0版本的策略，即语句执行结束后才释放锁 2.这个参数设置为1 普通insert语句，自增锁在申请之后就马上释放 类似insert … select这样的批量插入数据的语句， 自增锁还是要等语句结束后才被释放 3.这个参数设置为2，所有的申请自增主键的动作都是申请后就释放锁 为了数据的一致性，默认设置为1 如果sessionB申请了自增值以后马上就释放自增锁，那么就可能出现这样的情况
7.3K40编辑于 2022-09-06 - 来自专栏飞天小牛肉
MySQL 的自增主键一定是连续
但实际上，MySQL 的自增主键并不能保证一定是连续递增的。 回退回去的话不就不会发生自增 id 不连续了吗？ 事实上，这么做的主要原因是为了提高性能。 我们直接用反证法来验证：假设 MySQL 在事务回滚的时候会把自增值改回去，会发生什么？ 图片 而为了解决这个主键冲突，有两种方法： 每次申请 id 之前，先判断表里面是否已经存在这个 id，如果存在，就跳过这个 id 把自增 id 的锁范围扩大，必须等到一个事务执行完成并提交，下一个事务才能再申请自增 自增值不连续场景 4 对于批量插入数据的语句，MySQL 有一个批量申请自增 id 的策略： 语句执行过程中，第一次申请自增 id，会分配 1 个； 1 个用完以后，这个语句第二次申请自增 id，会分配 ，因为这类语句在申请自增 id 的时候，是可以精确计算出需要多少个 id 的，然后一次性申请，申请完成后锁就可以释放了。
4.5K10编辑于 2023-01-11 - 来自专栏帘卷西风的专栏
关于mysql自增id的获取和重置
缺点：获取的不是真正的自增id，是表中最大的Id，如果有删除数据的话，那么该值和自增id相差比较大。如果有连表数据，有可能导致数据错乱。 使用LAST_INSERT_ID函数：select LAST_INSERT_ID() 优点：获取到的是真正的自增id。 缺点：该函数是与table无关的，永远保留最新插入的自增列的id。 使用mysql查询函数：SHOW TABLE STATUS; 优点：能够准确的查到自增id。而且可以在语句后面加上where语句或者like语句来过滤。 缺点：该语句返回的是一个记录集，不能单独的返回自增值。所以需要额外的操作来获取。 使用自定义查询方法：mysql表相关的信息是放在information_schema表里。 ---- mysql自增id的重置 使用truncate：truncate table； 说明：使用truncate会删除表的数据释放空间，并且重置字自增id，但不会删除表的定义。
13.2K20发布于 2018-08-03 - 来自专栏爱可生开源社区
技术分享 | 关于 MySQL 自增 ID 的事儿
当我们使用 MySQL 进行数据存储时，一般会为一张表设置一个自增主键，当有数据行插入时，该主键字段则会根据步长与偏移量增长（默认每次+1）。 自增的值并不是保存在表结构信息内的，对于不同的版本它们有如下的区别： 1.1.1 MySQL 8.0版本之前（重启后可能会产生变化）： 计数器的值存储在内存中的，重启后丢弃，下一次将读取最大的一个自增ID ，不是事务结束 连续模式：批量插入时锁持有到该语句执行结束，简单插入时锁持有到申请完自增ID后即释放，并非直到语句完成 1.4 计数器的三种模式（innodb_autoinc_lock_mode） 通过调整 由于锁的粒度减少，多条语句在插入时进行锁竞争，自增长的值可能不是连续的。 不一定，业务也不应该过分依赖 MySQL 自增 ID 的连续性，在以下三种情况下，并不能保证自增 ID 的连续性： 1.5.1 插入时的其他唯一索引冲突 假设已存在数据{1,张三}，且张三所属的字段设置了唯一主键
4.8K10编辑于 2022-02-09
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号