신원 열 다시 시드 : 필요할 때?

대학에서 마지막 강의 중 하나 (학생)는 강사가 데이터베이스 (데이터가 필요한 경우 MySQL 서버)와 데이터베이스를 데이터 소스로 사용하는 소형 클라이언트 앱을 개발하도록 요청했습니다.

요구 사항 중 하나는 자격 증명 열 (모든 테이블의 PK)이 순차적이어야한다는 것입니다 (강사 단어별로). 즉, 테이블 행이 삭제되면 후속 삽입에서 PK를 재사용해야합니다. RDBMS, PK 및 ID 열에 대한 평균 지식이 있습니다. 내가 이해 한 바에 따르면, ID 열은 행을 삽입 할 때 DB가 PK를 자동 생성하고 더 이상 아무것도하지 않도록하는 방법 일뿐입니다. 그리고 식별 컬럼 값은 자연 속성이 아닌 한 어떤 식 으로든 행 속성과 관련되어서는 안됩니다.

이 요구 사항 (엄격히 순차적 인 ID 열)은 나에게 의심되었습니다. ID가 순차적이지 않은 경우 (삭제로 인한 간격이있는 경우) 강사에게 무엇이 잘못되었는지 묻려고했지만 "사용자에게 편리하고 데이터베이스를 유지 관리하는 DB 관리자에게 유용합니다"와 같은 매우 추상적 인 답변을 얻었습니다. 구체적인 예가 없습니다. "사용자에게 편리"라는 주장은 비즈니스 영역에서 의미가 없기 때문에 어리석게 들립니다.

따라서 이러한 이유가 진짜인지 궁금합니다. ID 열이 시드되어야하는 경우 (ID 공간이 소진 된 경우) 만 생각할 수 있습니다. 그러나 이것은 식별 열 유형이 잘못 선택되었을 때보 다 디자인 문제입니다. int대신 간단 하지 bigint않거나 uniqueidentifier테이블에 10 억 행이 포함되어 있습니다. ID 열이 클러스터 된 인덱스라고 가정합니다. ID 열의 간격이 인덱스 성능에 영향을 줄 수 있습니까? 어쩌면 내가 알지 못하는 각 삭제 후에 자동 ID 열이 다시 시드되는 다른 실제 이유가 있습니까?

미리 감사드립니다!

즉, 테이블 행이 삭제되면 후속 삽입에서 PK를 재사용해야합니다.

강사는 어느 우주에서 왔습니까?

그것은 비효율적입니다. 그렇게하면 성과 전망을 10 배나 줄일 수 있습니다.

감사를 위해 빈틈없는 숫자가 필요한 경우 데이터베이스 도구에서 직접 작성하지 말고 명시 적으로 작성하십시오. 행을 삭제하지 말고 "삭제됨"으로 플래그를 지정하십시오. 이러한 행을 무시해야하므로 쿼리가 지저분해질 수 있습니다.

MySQL에서 InnoDB는 PRIMARY KEY각 테이블마다 고유 해야합니다. 그러나 그것은 요구 사항의 범위입니다. 키는 문자열 일 수도 있습니다.

간격은 사용자와 DBA에게 편의 이며 불편 하지 않습니다 .

나는 한 번에 100 개의 행 그룹으로 청킹하는 틈이없는 편리한 사례를 생각할 수 있습니다. 그러나을 사용하는 간단한 해결 방법이 LIMIT 100,1있습니다.

간격은 성능에 전혀 영향을 미치지 않습니다. 여기에는 숫자가 아닌 인덱스가 포함됩니다. 고유하지 않은 인덱스. 복합 인덱스.

물론 ID가 부족할 수 있습니다. 나는 거의 20 년 동안 MySQL을 사용하여 두 번 일어나는 것을 보았습니다. 소행성에 충격을받을 수도 있습니다. 밤에 내가해야 할 일이 적다.

간격은 (적어도)에서 발생 : INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(명시 적 또는 때문에 충돌하는), (갈레 및 그룹 복제 포함) 멀티 마스터 복제. 정말로 그 해결 방법을 제시하고 싶습니까?!

강사가 의심스러워하는 말이 있으면 건전성 검사를 받도록하십시오.

신원 가치를 재사용하는 것은 일반적으로 권장되지 않습니다. 값이 전체적으로 내부적으로 사용되는 경우 실제 값이 중요하지 않거나 외부에서 사용되는 경우 값을 재사용하면 잘못 식별 될 수 있습니다.

송장 또는 구매 주문 번호의 명백한 사례를 생각해보십시오.이 번호는 ID 열에서 쉽게 가져와 외부에 노출 될 수 있지만 그러한 이유로 정확하게 재사용하고 싶지는 않습니다. 둘 다 당신이 혼란스럽고 싶지 않은 특정 거래를 말합니다.

이러한 문제를 해결하는 것은 회사가 합병하거나 인수 할 때 큰 번거 로움이 될 수 있습니다. 고의로 그러한 문제를 만드시겠습니까? 현명하지 않다.

PK id 값의 재사용에는 문제가 있으므로 일반적으로 피해야합니다.

먼저 auto_increment 열을 구현한다고 틈이 없다고 보장 할 수는 없습니다. 자동 증분 열에서 삽입을 롤백하면 실제로 간격이 발생합니다.

두 번째로 갭 ID는 삭제되지 않은 기존 데이터 (FK 제한 누락으로 인해)를 나타낼 수 있습니다. 이들이 시스템 외부에서 통신 한 구성원 번호로 변환되면 잠재적 인 비즈니스 신원 위험이 있습니다.

셋째, bigint unsigned삽입 률이 매우 높더라도 상당한 시간 동안 ID가 부족하지 않습니다.

차이가있는 가장 큰 고통은 감사 결함을 주장하는 감사원들 사이에 오는 것입니다. DBA에게는 차이가 존재한다는 이유와 그 이유를 알고 있습니다.

나는 PK를 재사용하는 것이 좋지 않다는 다른 사람들의 의견을 반향하지는 않지만 ID 열을 다시 시드 해야하는 시대를 맞이했습니다.

PK 인덱스 자체가 손상되었습니다.

이것이 MS-SQL을 사용하고 있으며 수년 전에는 많은 관련이 있었지만 여전히 관련이 있습니다. 몇 년 전, 내가 일하는 회사의 누군가는 클라이언트가 사용하기에 너무 오래되어 150 개 이상의 원격 위치에서 PC를 서버로 재사용하고 옷장에 붙이는 것이 좋은 생각이라고 생각했습니다. 환기가되지 않습니다. 우리가 모두 미션 크리티컬 데이터베이스를 120 개 이상 실행하는 작은 방에 10 년 된 정크 컴퓨터 더미가 있으면 좋은 결과 만 얻을 수 있다는 것을 모두 알고 있기 때문입니다. 40 %의 실패율과 저의 경력 선택을 다시 생각합니다. 우리는 회사 본사에 데이터를 다시 복제 할 것이지만, 이러한 실패로 인해 데이터베이스에 나쁜 일이 발생할 수 있습니다. 그중 하나는 데이터베이스에 손상된 인덱스가있어 데이터베이스와 복제 프로세스를 포착 할 수있었습니다. 이 훌륭한 환경에서 두 번 복제를 해결하는 유일한 솔루션은 인덱스를 다시 시드 한 다음 복제를 다시 설정하는 것입니다. 서버를 완전히 제거하기 전에 나중에 서버를 교체했습니다.