2011-03-05 10 views
0

원격 사용자로부터받은 업데이트 패킷을 저장하는 데 사용되는 MySQL 데이터베이스가 있습니다. 매 5 ~ 10 건마다 업데이트되며, 본질적으로 집합 업데이트 패킷을 만드는 몇 가지 추가 코드가 실행됩니다. 이 접근 방식을 통해 사용자는 업데이트 패킷 0에서 상태를 다시 생성하지 않고도 응용 프로그램에 대한 최신 정보를 얻을 수 있습니다.활성 MySQL 데이터베이스의 식별자 재설정

관계형 참조가 끊어지기 때문에 데이터베이스 인덱스를 다시 사용하는 것이 일반적으로 좋지 않다는 것을 알고 있습니다. 제 경우에는 업데이트 패킷 데이터를 참조하는 보조 테이블이 없습니다. 인덱스는 아직 처리되지 않은 업데이트를 결정하기 위해 클라이언트 응용 프로그램에서만 사용됩니다. 몇 달 동안의 일반적인 사용 후에 자동 증가 인덱스는 일괄 업데이트 패킷에 대한 액세스로 인해 분명히 매우 커지고 필요한 값을 훨씬 넘어 설 것입니다. 따라서 특정한 경우 집합적인 업데이트 패킷을 생성 한 후에 인덱스를 재설정하는 것이 합리적일까요?

엄청난 양의 데이터베이스 경험이 없으므로 여기서 기술을 간과 할 수 있습니다. 올바른 방향으로 나를 가리 키십시오. 감사!

답변

2

나는 우리가 일반적으로 "식별자"라고 부르는 것을 언급 할 때 "색인"이라는 용어를 사용한다는 것을 알기 전까지이 질문을 약간 혼란스러워했습니다.

예, 일반적으로 기본 키 값을 다시 사용하는 것은 좋지 않은 방법입니다. (이상적으로 기본 키 값은 단순하고 고유하며 불변하며 익명입니다.)

당신이 말하는 것은 테이블에 AUTO_INCREMENT 열이 있으며 테이블에 많은 행을 삽입하고이 값 테이블의 PRIMARY KEY로 사용되지 않습니다. (테이블을 참조하는 외래 키가 없으므로 테이블에 PRIMARY KEY가 정의되어 있지 않아도됩니다.)

BIGINT UNSIGNED의 데이터 유형을 사용하면 10의 순서로 표시됩니다 ** 가능한 19 가지 값.

AUTO_INCREMENT 값을 다시 설정해야하는지 알 수 없습니다. 어떤 경우 든 저장 한 가장 높은 값보다 낮은 값으로 재설정 할 수 없으므로 테이블을 더 낮게 설정하려면 테이블에서 행을 제거해야합니다.

+0

잘못된 용어 사용에 대해 사과드립니다. 모든 업데이트를 자동화 할 수 있어야하므로이 데이터베이스에 대한 유지 관리 작업을 수행하고 싶지 않습니다. 저는 개념적으로 구현을 스택으로 생각하고 있으며, 높이가 10에 도달하면 패킷이 단일 업데이트로 축소됩니다. 스택의 맨 아래에 모든 업데이트를 포함하기 때문에 한 번에 10 개의 업데이트를 저장하는 데 기술적으로 필요한 테이블 만 필요합니다. 10 개의 업데이트마다 테이블을 다시 만들어야합니까? – Xenethyl

1

매우 높은 번호의 자동 증가 ID는 실제로 문제가되지 않아야합니다. bigint를 사용하는 경우 수십 년 동안 초당 1,000 개를 만들 수 있습니다.

+0

대용량 ID와 함께 사용하는 것이 맞는지 확인해 주셔서 감사합니다. 나는 bigints를 저장하는 추가 오버 헤드가 바람직하지 않다고 생각했기 때문에이 경로를 벗어나는 경향이있었습니다. 실제로 나는 그렇게 나쁘지 않다고 생각하니? – Xenethyl

관련 문제