MySQL의 기본 키 자동 증가에 대해 자세히 알아보기

이 기사에서는 MySQL의 자동 증가 기본 키를 이해하고, 자동 증가 값 수정 메커니즘, 자동 증가 값 수정 타이밍, 자동 증가 잠금 최적화 방법 등을 소개합니다. 도움이 필요한 친구가 배울 수 있습니다~

1. 자체 증가된 값은 어디에 저장되나요?

엔진마다 자체 증분 값을 저장하는 전략이 다릅니다

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 로그에 의존합니다.

2. 자체 증가 값 수정 메커니즘

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

의 현재 자동 증가 값 2를 얻습니다. 3. 들어오는 행의 값을 다음으로 변경합니다. (2,1,1)4. 테이블의 자동 증가 값을 3

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

으로 설정됩니다. 자동 증분 잠금은 적용 후 즉시 해제됩니다

데이터를 일괄 삽입하는 insert...select 문과 유사하지만 자동 증가 잠금은 해제되기 전에 문이 완료될 때까지 기다려야 합니다

3 이 매개 변수는 2로 설정되며 자동 증가 기본 키에 적용되는 모든 작업은 응용 프로그램 잠금 후에 해제됩니다.

데이터 일관성을 위해 기본 설정은 1

sessionB가 자동 증가 값을 적용하고 해제하는 경우 자동 증가 잠금이 즉시 발생하면 다음 상황이 발생할 수 있습니다.

sessionB는 먼저 자동 증가 ID에 적용된 데이터의 두 행 (1,1,1), (2,2,2)

sessionA를 삽입하고 id=3을 삽입한 후 sessionB는 계속 실행되어 두 개의 레코드(4, 3,3), (5,4,4)
• binlog_format=statement일 때 두 세션이 삽입되었습니다. 데이터 삽입 명령을 동시에 실행하므로 binlog에 있는 테이블 t2의 업데이트 로그에는 두 가지 상황만 있습니다. 먼저 기록하거나 세션A의 경우 세션B를 먼저 기록합니다. 어느 쪽이든 이 binlog는 슬레이브 데이터베이스에서 실행되거나, 대기 데이터베이스와 임시 인스턴스를 복원하는 데 사용되며, 생성된 결과의 ID는 연속됩니다. 이때 이 라이브러리에서 데이터 불일치가 발생했습니다.

이 문제를 해결하기 위한 아이디어:

1) 원본 라이브러리의 일괄 삽입 데이터 문이 연속적인 ID 값을 생성하도록 합니다. 따라서 이 목적을 달성하기 위해 명령문이 실행될 때까지 자체 증가 잠금이 해제되지 않습니다

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$）为例，通过下面这个语句序列验证一下：

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 중국어 웹사이트의 기타 관련 기사를 참조하세요!