河北正规网站建设比较,网页制作平台哪家好,qq空间网站域名怎么做的,深圳市新朗建设工程有限公司网站概述
MySQL中的自增特性估计大家或多或少都是用过。一张表中只能由一个自增字段#xff0c;通常我们会把它设置为主键#xff0c;但是随着大家系统越来越分布式#xff0c;为了一些性能和可扩展性问题#xff0c;大家目前选择更多的都是分布式ID#xff08;雪花算法、UUI…概述
MySQL中的自增特性估计大家或多或少都是用过。一张表中只能由一个自增字段通常我们会把它设置为主键但是随着大家系统越来越分布式为了一些性能和可扩展性问题大家目前选择更多的都是分布式ID雪花算法、UUIDRedis ID Leaf。
但是我觉得还是有必要谈一下自增变量为什么要持久化或许可以为大家以后设计一些系统作为参考。
自增使用
我们先来看看MySQL自增的使用自增可以在CREATE TABLE和ALTER TABLE使用:
建表时指定自增修改列为自增
建表时指定自增
建表时指定自增列: create table trade_user(id int not null auto_increment primary key,name varchar(20) not null default comment name
)commenttrade user;COPY 修改列为自增 create table trade_user1(id int not null primary key,name varchar(20) not null default comment name
)commenttrade user;ALTER TABLE trade_user1 modify id INT NOT NULL auto_increment;COPY 自增模式
表中的自增列有一个专用的锁AUTO-INC锁这个锁保证并发场景下没有问题。
AUTO-INC锁这个锁有几种模式MySQL 8默认的模式为交错模式我们来查看下MySQL 8默认的锁模式 SHOW VARIABLES LIKE innodb_autoinc_lock_mode;COPY 我们看到Value为2,2是什么来查个表
值自增锁模式备注0“传统”模式为每个语句获取表级自增锁并在语句结束时释放。1“连续”模式在查询执行的第一次自增ID的生成时获取表级自增锁并在语句结束时释放。多个并发的自增语句可以同时获取ID并执行。2“交错”模式只在自增ID需要的时候获取行级的自增锁。这种方式可以大大降低锁的竞争提高并发性能但可能会因事务的回滚导致自增ID的不连续。
默认模式
MySQL版本默认值自增锁模式5.10“传统”模式5.1 – 5.71“连续”模式8.02“交错”模式
自增问题
交错自增锁的问题是什么我们来看看官方的解释 The default setting is 2 (interleaved) as of MySQL 8.0, and 1 (consecutive) before that. The change to interleaved lock mode as the default setting reflects the change from statement-based to row-based replication as the default replication type, which occurred in MySQL 5.7. Statement-based replication requires the consecutive auto-increment lock mode to ensure that auto-increment values are assigned in a predictable and repeatable order for a given sequence of SQL statements, whereas row-based replication is not sensitive to the execution order of SQL statements. 持久化
遇到了什么问题需要持久化我们来看个MySQL的bugbug链接MySQL Bugs: #199: Innodb autoincrement stats los on restart 这个bug大概描述了MySQL交错模式自增导致的问题复现步骤
创建一个名为“a”的表其id字段设置为自增字段。向表中插入三条记录到此为止生成的id值分别为1, 2, 3。删除id3的记录在表中再次插入一条记录新记录的id值为4因此当前表中的id值为1, 2, 4。删除id4的记录此时MySQL服务器重启。重启后向表中再次插入一条记录新插入的记录的id值变为了3这就是AUTO_INCREMENT字段生成重复值的情况。
根据描述这个问题可能导致的问题是复制中断因为在主从复制中主库和从库的AUTO_INCREMENT值可能会不同从而导致主从数据不一致。
没有持久化自增值之前怎么得到自增值
这个我们自己思考下就可以想到首先自增变量肯定要放到内存里面并且与表有一一对应关系然后自增变量要存储到某个地方以便下次服务启动时读取。
MySQL的思路基本和上面差不多MySQL的自增变量恢复遵循以下步骤
首先表的自增值肯定是要放到内存中的其次 我们需要思考哪儿有这个自增值就是表字段然后MySQL通过查询表的元数据来定位和获取自增字段的最大值。最后MySQL执行一条SQL就可以获取了 SELECT MAX(auto_increment_column) FROM tableCOPY
例如要查询’trade_user’表中’id’字段的最大值可以使用以下SQL select max(id) from trade_userCOPY
持久化之后自增ID放到哪儿了
放到了information_schema数据字典中了如果你要查询你表的当前的自增ID值执行下面这条SQL: SELECT AUTO_INCREMENT
FROM information_schema.tables
WHERE table_schema blog
AND table_name trade_user1;COPY 再进一步到底怎么存储的
先看MySQL官方怎么说 In MySQL 8.0, this behavior is changed. The current maximum auto-increment counter value is written to the redo log each time it changes and saved to the data dictionary on each checkpoint. These changes make the current maximum auto-increment counter value persistent across server restarts. 这个大概意思就是MySQL会把自增计数器的当前最大值写入redo log并在每次检查点时保存到数据字典中这样就完成了自增计数器的持久化。 数据库重启了以后怎么恢复因为重启可能是因为崩溃最新的自增值还没有写入到数据字典中那么就得这么干了
数据库启动的时候先从数据字典中获取元数据把表的自增ID加载到内存中服务器重放redo log中的所有事务然后把自增ID修改为redo log中的值
总结
从MySQL自增值持久化问题以及解决方案我们从中可以学习到
数据持久化和一致性的重要性设计系统时要考虑到异常情况如果没有考虑到异常情况出一些意料之外的问题你会很蒙蔽全局唯一ID的重要性这个ID非常重要要是混乱了你的饭碗可能瞬间都没了而且后面的就刷库吧
参考
1. MySQL自增变量持久化 – FOF编程网
创作不易难免会有点错误或者可读性问题请大家理解
