2^32로 충분하지 않다면 어떨까요?

테이블에 항목이 너무 많아서 주어진 기간 (일, 주, 월, ...) 내에 auto_increment ID가 2^32이면 충분하지 않습니다.
MySQL에서 제공하는 최대 데이터 유형이 충분하지 않은 경우 어떻게해야합니까?2^32로 충분하지 않다면 어떨까요?

고유 ID가 필요한 내 테이블에 많은 항목이 추가되는 상황을 어떻게 해결해야하는지 궁금하지만 한 기간 내에 데이터 유형을 채우고 싶습니다.

기본적으로 MySQL (또는 다른 시스템) 내에서 무제한의 고유 ID를 얻거나 적어도 기하 급수적으로 증가시킬 수 있습니까?

이상적으로는 기하 급수적으로 항목의 양을 증가

> SELECT * FROM table; 

+---+------+ 
| a | b | 
+---+------+ 
| 1 | 1 | 
| 1 | 2 | 
| 1 | 3 | 
|...| .... | 
|...| .... | 
| 1 | 2^32 | 
| 2 | 1 | 
| 2 | 2 | 
+---+------+

같은 것을 기대하는 것입니다.

어떻게 이러한 상황에 대처하십니까?
기억하십시오 - 요구 사항은 모든 항목에 대해 고유 한 ID를 갖는 것입니다.

출처

2009-03-31 michal kralik

관심은 MySQL은 비록 GUID를 기본적으로 지원했다 생각하지 않았다 높은 ID를 –

기본 키는 BIGINT를 사용할 수 있습니다. 이것은 기본적으로 64 비트 숫자입니다.

편집 # 2 : 이전에 BIGINT 바이트 길이를 변경하기 전에 내가 말한 것은 틀 렸습니다. BIGINT 은이며 8 바이트 제한으로 고정되어 있습니다.

출처

2009-03-31 20:49:33

http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html BIGINT가 8 바이트로 고정되어 있음을 의미합니까? –

실제로 Rowland가 말하는 것은 정확합니다. BIGINT는 항상 64 비트입니다. 숫자 데이터 유형과 연관 될 수있는 숫자는 표시 너비 만 정의하고 저장 용량에 영향을 미치지 않습니다. –

저는 8 바이트와 64 비트가 똑같은 것을 혼동하고 있습니까? 그래서 편집을 유질? –

128 비트 키만 사용하십시오. 우주의 원자 수보다 많은 행을 매우 빨리 허용하기 때문에 무제한의 키가 필요하지 않습니다. (어딘가에 약 256 비트).

출처

2009-03-31 20:47:13 Eclipse

는 autoincrementing 기본 키를 사용하지 마십시오 - 위키 백과 기사 - 사용 GUID 또는 유사한 :

각 GUID를 생성하는 동안은 고유합니다 , 고유 키의 총 수 (아니다 2^128 또는 3.4 × 10^38)은 너무 커서 동일한 숫자가 두 번 생성 된 확률이 무한히 입니다. 예를 들어, 관찰 가능 우주를 생각해보십시오. 여기에는 약 5 × 1022 개의 별이 포함되어 있습니다. 모든 별은 이며, 유니크 한 크기는 6.8 × 1015입니다. GUID.

출처

2009-03-31 20:48:30 Rich

을 필요로 데이터의 종류를 알고? –

그러면 필요한 것을 처리 할 수있는 RDMS를 얻으십시오. – Eclipse

"생일 역설"을 찾으십시오. 2^64 GUID를 생성 할 때 동일한 GUID를 두 번 가져올 확률은 실제로 50 %입니다. 따라서 64 비트 자동 증가 형을 사용하는 것보다 이점이 없습니다. –

나는 MySQL의에서 자동으로 생성 한 다음, 그들은 반드시 순차적하지 않을 방법을 잘 모르겠어요,하지만 난 당신이 작성 그들에 대해 걱정할 필요가 없습니다 GUID를 사용하여 수 있다는 확신 쪽으로.

출처

2009-03-31 20:48:39 dustyburwell

저는 2^64에 대해 BIGINT로 이동하여 시작할 것입니다. GUID는 또 다른 옵션이 될 수 있지만 이러한 항목을 "일부 형식"으로 저장해야합니다.

출처

2009-03-31 20:51:53

키 열에 chars/varchars를 사용하고 키에 GUID를 사용할 수도 있습니다. 비록 정수 기본 키와 비교할 때 성능상의 불이익이 발생할지 모르겠다.

출처

2009-03-31 20:52:17 Kevlar

키에 다른 열을 추가하면 두 번째 열의 훨씬 작은 인덱스에도 불구하고 실제로 수행해야하는 인덱스 스캔 수가 두 배가됩니다.

앞에서 설명한 것처럼 VAST 데이터 세트의 가장 좋은 방법은 GUID (RDBMS에서 네이티브로 지원하는 경우) 또는 varchar (16) 중 하나입니다.

이 포함 된 VARCHAR/VARBINARY를 사용하는 방법에 대한 좋은 부분은 필요한 경우 자동으로, 미래에 열을 확장 할 수 있다는 점이다. 그리고 나쁜 부분은 정수에 비해 varchar/varbinary가 성능이 좋지 않은 키라는 것입니다.

출처

2009-03-31 22:05:18

당신이이 문제가 발생 너무 많은 데이터가있는 경우는, 다음 기본 키를 선택하는 것은 아마 우려의 이상이다.

InnoDB 엔진을 사용하는 경우 자주 검색 할 기본 키 (특히 검색에서 많은 행이 반환되는 위치)를 선택하는 것이 성능 향상에 도움이 될 수 있습니다. 범위 스캔을 개선합니다.

출처

2009-03-31 22:13:30 MarkR

당신은 BIGINT UNSIGNED이 충분하다 생각하지 않아? 18.446.744.073.709.551.615 또는 하루 50.539.024.859.478.223 항목 (365, D/Y), 시간당 2.105.792.702.478.259 항목 분당 35.096.545.041.304 엔트리 한 년도 - 즉, 0의 범위이다 또는 584.942.417.355/초입니다.

With assumed 600 writes per second (without any reads) 당신은 항목을 전체 쓰기 속도 974.904.028 년을 작성할 수 있습니다. 그 정도면 충분합니다.

출처

2009-03-31 22:20:36

2^32로 충분하지 않다면 어떨까요?

답변

관련 문제