집 >데이터 베이스 >MySQL 튜토리얼 >MySQL의 기본 키 자동 증가에 대해 자세히 알아보기
이 기사에서는 MySQL의 자동 증가 기본 키를 이해하고, 자동 증가 값 수정 메커니즘, 자동 증가 값 수정 타이밍, 자동 증가 잠금 최적화 방법 등을 소개합니다. 도움이 필요한 친구가 배울 수 있습니다~
엔진마다 자체 증분 값을 저장하는 전략이 다릅니다
1. MyISAM 엔진의 자체 증분 값은 데이터 파일에 저장됩니다.
2 MySQL5에서 InnoDB 엔진의 자체 증분 값은 다음과 같습니다. .7 및 이전 버전에서는 자체 증가된 값이 메모리에 저장되며 지속성이 없습니다. 다시 시작할 때마다 테이블을 처음 열면 최대 자동 증가 값인 max(id)를 찾은 다음 테이블의 현재 자동 증가 값으로 max(id) + step size를 사용합니다
select max(ai_col) from table_name for update;
MySQL 버전 8.0에서는 redo 로그에 자체 증가 값의 변경 사항을 기록하고, 재시작 시 재시작 전 값을 복원하기 위해 redo 로그에 의존합니다.
If 필드 ID는 AUTO_INCREMENT로 정의됩니다. 데이터 행을 삽입할 때 자동 증가 동작은 다음과 같습니다.
1 데이터 삽입 시 ID 필드가 0, null 또는 지정되지 않은 값으로 지정된 경우 이 테이블의 현재 AUTO_INCREMENT 값을 자동 증가 필드에 넣습니다.
2. 데이터를 삽입할 때 id가 필드에 특정 값을 지정하는 경우 삽입할 값이 X라고 가정하고, 현재 자동 증가 값은 Y입니다. 1. 변경된 경우
2. 긴 경우 다음보다 큰 첫 번째 값까지 계속 중첩합니다. 인덱스 및 테이블 생성 문은 다음과 같습니다.
CREATE TABLE `t` ( `id` int(11) NOT NULL AUTO_INCREMENT, `c` int(11) DEFAULT NULL, `d` int(11) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `c` (`c`)) ENGINE=InnoDB;
이미 레코드가 있다고 가정합니다. 1,1,1) 그런 다음 데이터 삽입 명령을 실행합니다.
insert into t values(null, 1, 1);
실행 프로세스는 다음과 같습니다.
1. 실행 프로세서는 전달된 이 행의 값을 쓰기 위해 InnoDB 엔진 인터페이스를 호출합니다. in은 (0,1,1)2입니다. InnoDB는 자동 증가 ID를 지정하지 않은 값을 찾아 테이블 t
5로 변경합니다. 이미 c=1의 레코드가 있으므로 계속해서 키가 중복됩니다. )이 보고되고 해당 명령문은
을 반환합니다. 해당 실행 흐름도는 다음과 같습니다.
이후 새 데이터 행을 삽입할 때 획득되는 자동 증가 ID는 3입니다. 자체 증가 기본 키가 불연속적인 상황이 발생합니다고유 키 충돌 및 트랜잭션 롤백으로 인해 자체 증가 기본 키 ID가 불연속적인 상황이 발생합니다
자체 증가 잠금 최적화
Auto-increasing id 잠금은 각 적용 후 즉시 트랜잭션 잠금이 해제되어 다른 트랜잭션이 다시 적용될 수 있도록 합니다.
그러나 MySQL 5.0 버전에서는 자체 증가 잠금의 범위가 명령문 수준입니다. . 즉, 명령문이 테이블 자동 증가 잠금에 적용되는 경우 명령문이 실행될 때까지 잠금이 해제되지 않습니다. MySQL 버전 5.1.22에는 새로운 매개변수 innodb_autoinc_lock_mode가 도입되었으며 기본값은 1
입니다. 1. 이 매개변수는 0으로 설정됩니다. 이는 이전 MySQL 5.0 버전의 전략을 채택한다는 의미입니다. 즉, 명령문이 실행된 후 잠금이 해제됩니다
2. 일반 삽입의 경우 이 매개변수는 1
으로 설정됩니다. 자동 증분 잠금은 적용 후 즉시 해제됩니다3 이 매개 변수는 2로 설정되며 자동 증가 기본 키에 적용되는 모든 작업은 응용 프로그램 잠금 후에 해제됩니다.
데이터 일관성을 위해 기본 설정은 1
sessionB가 자동 증가 값을 적용하고 해제하는 경우 자동 증가 잠금이 즉시 발생하면 다음 상황이 발생할 수 있습니다.sessionB는 먼저 자동 증가 ID에 적용된 데이터의 두 행 (1,1,1), (2,2,2)
2)在binlog里面把插入数据的操作都如实记录进来,到备库执行的时候,不再依赖于自增主键去生成。也就是把innodb_autoinc_lock_mode设置为2,同时binlog_format设置为row
如果有批量插入数据(insert … select、replace … select和load data)的场景时,从并发插入数据性能的角度考虑,建议把innodb_autoinc_lock_mode设置为2,同时binlog_format设置为row,这样做既能并发性,又不会出现数据一致性的问题
对于批量插入数据的语句,MySQL有一个批量申请自增id的策略:
1.语句执行过程中,第一次申请自增id,会分配1个
2.1个用完以后,这个语句第二次申请自增id,会分配2个
3.2个用完以后,还是这个语句,第三次申请自增id,会分配4个
4.依次类推,同一个语句去申请自增id,每次申请到的自增id个数都是上一次的两倍
insert into t values(null, 1,1); insert into t values(null, 2,2); insert into t values(null, 3,3); insert into t values(null, 4,4); create table t2 like t; insert into t2(c,d) select c,d from t; insert into t2 values(null, 5,5);
insert … select,实际上往表t2中插入了4行数据。但是,这四行数据是分三次申请的自增id,第一次申请到了id=1,第二次被分配了id=2和id=3,第三次被分配到id=4到id=7
由于这条语句实际上只用上了4个id,所以id=5到id=7就被浪费掉了。之后,再执行insert into t2 values(null, 5,5)
,实际上插入了的数据就是(8,5,5)
这是主键id出现自增id不连续的第三种原因
自增主键字段在达到定义类型上限后,再插入一行记录,则会报主键冲突的错误
以无符号整型(4个字节,上限就是 2 32 − 1 2^{32}-1 232−1)为例,通过下面这个语句序列验证一下:
CREATE TABLE t ( id INT UNSIGNED auto_increment PRIMARY KEY ) auto_increment = 4294967295; INSERT INTO t VALUES(NULL); INSERT INTO t VALUES(NULL);
第一个insert语句插入数据成功后,这个表的AUTO_INCREMENT没有改变(还是4294967295),就导致了第二个insert语句又拿到相同的自增id值,再试图执行插入语句,报主键冲突错误
相关学习推荐:mysql教程(视频)
위 내용은 MySQL의 기본 키 자동 증가에 대해 자세히 알아보기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!