MySQL: 8.0.31 - 몇 개월 사용 후 ID 필드에 큰 차이(수천 개)가 발생합니다.
mysql 8.0.31 릴리스 버전에서 auto_messages가 포함된 기본 키 열은 여러 테이블에서 큰 차이를 보입니다(기본값 - innodb_autoinc_lock_mode = 2("interleaved" 잠금 모드).또한 이 모드에서는 약간의 차이가 발생할 수 있습니다.
'order' 테이블(id bigint)과 'order_line_items' 테이블(id bigint)이 있습니다.
TABLE_NAME | CURRENT AUTO_INCREMENT | TABLE ROW COUNT
order | 27504 | 1367
order_line_items | 430930 | 34970
현재 자동 증분 값이 '27504'인 주문 행은 총 1367개이며, 현재 자동 증분 값이 '430930'인 34970개(주문 라인 항목 행)가 있습니다.API 호출에서 동일한 트랜잭션 내에서_line_items를 모두 저장, 정렬 및 정렬합니다(트랜잭션 롤백으로 이어질 수 있는 오류 가능성 있음).
차이:
일단 눈치채고 오늘부로 다시 '1'씩 증가로 돌아선 후 1~2일 동안 오더 테이블 간격이 계속 발생했습니다.점프가 클러스터에서 연속적으로 발생하고(아래 확인) '1'씩 증가로 돌아갔습니다.
Order table gap details:
id | difference from previous 'id'
-------------------------------------
27489 1
27488 1
27487 1
27486 232
27254 232
27022 693
26329 240
26089 401
25688 175
25513 348
25165 864
24301 7656
16645 1709
14936 184
14752 13
14739 541
14198 82
14116 215
13901 68
13833 117
13716 140
....
1468 1
1467 10
1457 1
1456 1
1455 1
1454 9
1445 1
1444 1
1443 1
1442 1
1441 1
관측치:
(OpenJPA) 구성을 사용합니다(@Id, @GeneratedValue(전략 = GenerationType).IDENTITY)를 입력합니다.ID가 코드에 설정되어 있지 않습니다.
다른 테이블에서도 동일한 패턴을 볼 수 있습니다.20개의 스레드로 동일한 API를 병렬로 생성하여 테스트했지만 두 테이블 모두에 대해 생성 ID의 큰 차이는 없었습니다.
Till id: 1445(1225개 행 수)의 순서 표에서 더 큰 점프에는 문제가 없습니다.id: 1445 이후에, 우리는 1-2일 동안 연속적으로 27487까지 순서대로 여러 번 점프하는 것을 보기 시작했습니다.
또한 API 호출에서 트랜잭션의 롤백이 자동 증가 값을 증가시킬 수 있다는 것을 이해하지만, 총 레코드에 비해 여러 번 더 큰 점프는 이해할 수 없는 것 같습니다.
질문:
이것의 원인이 무엇인지 아는 사람이 있습니까?순서 표의 총 레코드 수가 1367 미만일 때 id가 수천 개(예: 위의 예에서는 7656, 1709)로 급증하는 이유는 무엇입니까?
저는 이것이 ID가 점프하는 여러 개의 섬 클러스터에서 발생하는 것을 보고 하나씩 만들기 시작합니다(위의 예처럼).이것이 mysql 데이터 관련 프로세스의 다른 내부 처리와 관련이 있습니까?이것이 mysql에 있을 수 있는 버그입니까?
무엇이 'mysql'을 이렇게 더 높이 뛰게 할 수 있습니까(예: 대량 삽입, 공유 잠금이 이를 유발할 수 있습니까)?어떻게 하면 이 문제를 지역적으로 시뮬레이션할 수 있습니까?
어떤 아이디어든 정말 도움이 될 것입니다.
업데이트: 멀티 API 호출이 이루어졌지만, ids에 큰 차이가 발생한 당사 클라이언트 측의 예상치 못한 재시도로 인해 API 수준에서 실패했습니다.여러분 감사합니다.
ID "갭"은 다음과 같은 몇 가지 이유로 발생할 수 있습니다.
INSERT가 실패한 경우(예를 들어 유니크 또는 외래 키와 같은 다른 제약 조건과 충돌하는 경우) ID 생성은 취소되지 않습니다.행은 삽입되지 않지만 ID는 계속 증가하므로 값은 "손실"됩니다.
저는 그런 문제로 고객을 도운 적이 있습니다.▁the의 사용자 이름에 이 있었습니다.
users테이블, 그리고 몇몇 사람들은 계속해서 기존의 사용자 이름을 사용하여 웹사이트에서 새로운 사용자로 등록하려고 했습니다.이런 일이 매일 일어났고, 계속해서 증가했기 때문에 결국 하루에 약 1500개의 ID가 "잃어버린" 상태가 되었습니다.INSERT가 성공했지만 어떤 이유로 인해 응용프로그램에서 트랜잭션이 롤백된 경우.
가 1이 아닌 다른 것으로 설정된 경우.이 옵션은 세션에서 일시적으로 설정할 수 있는 옵션이므로 MySQL Server 구성 파일에 표시되지 않을 수 있습니다.하지만 아마 애플리케이션 코드에 있을 것입니다.
INSERT는 다음으로 큰 ID 값보다 높은 값을 지정하여 자동 증분을 재정의합니다.자동 증분은 테이블에서 가장 큰 값보다 낮은 값을 생성하지 않으므로 INSERT가 더 높은 값을 지정하면 다음 INSERT가 더 큽니다.그것은 그것이 남긴 공백을 채우지 못할 것입니다.
누군가 도망쳤습니다.
ALTER TABLE ... AUTO_INCREMENT=...테이블의 현재 다음 ID 값을 변경했습니다.InnoDB 버그.이러한 값은 드물지만 테이블이 1씩 엄격하게 증가하는 대신 자동 증분 값을 " 건너뛴" 경우도 있는 것으로 보고되었습니다.자동 증분은 고유한 값을 보장하지만 연속된 값은 보장하지 않습니다.
음, 우선, 삽입물 검사를 시작하지 않을 것입니다.그들은 여기서 거의 잘못이 없습니다.삽입은 어떻게 이루어집니까?API 호출이 실패하면 롤백하고, 그렇지 않으면 커밋할 것으로 예상됩니다. 그렇죠?그러나 트랜잭션이 실패해도 시퀀스는 롤백되지 않습니다.
API 호출 로그에 오류가 있는지 검색하겠습니다.만약 당신이 최대 1099를 가지고 있다면, 다음 삽입은 1104입니다. 저는 당신이 로그에서 4개의 오류와 정확하고 유효한 삽입을 찾을 것이라고 확신합니다.
시퀀스는 "멋지게 보이기" 위한 것이 아닙니다.예, 모든 제어 코드가 통과되면 당연히 각 레코드는 n + 1이고 (미학적 관점에서) "적절하게" 삽입됩니다.하지만 시퀀스는 그것에 관한 것이 아닙니다.안auto_incrementPK 또는 영국 제약 조건을 위반하지 않도록 하기만 하면 됩니다.그게 다야.그래서 어떤 용도로든, 그것에 상관없이.COMMIT또는ROLLBACK시퀀스가 "사용"됩니다.이는 설계상의 문제이며 데이터 무결성을 보장합니다.
이를 시뮬레이션하기 위해, 당신은 삽입 후 항상 롤백되는 사용자 정의 API 호출(또는 로컬 삽입)을 시도할 수 있습니다.그런 다음 현재 시퀀스 값을 확인합니다.auto_increment.
언급URL : https://stackoverflow.com/questions/74843356/mysql-8-0-31-large-gaps-thousands-in-id-field-after-few-months-of-usage
'programing' 카테고리의 다른 글
| refspec을 사용하여 Git 태그를 분기에 푸시하는 방법은 무엇입니까? (0) | 2023.06.28 |
|---|---|
| 엔티티 프레임워크 - 트랜잭션 내부의 'Save Changes' 앞에서 ID 검색 (0) | 2023.06.28 |
| Git에서 현재 수정본이 무엇인지 어떻게 알 수 있습니까? (0) | 2023.06.28 |
| Spring Boot 프로젝트에 메서드 기반 보안을 추가하려면 어떻게 해야 합니까? (0) | 2023.06.28 |
| Git는 서브모듈에 대한 커밋의 SHA1을 어디에 저장합니까? (0) | 2023.06.28 |