나는 현재 약 70M 행이고 수천명이 매일 증가하고있는 매우 큰 테이블을 가지고 있는데,이 스키마는 매일 바뀌어서 분할 된 테이블로 이동하고 있습니다. ddl 재 설계mysql 7columns pk 대 1 열 md5 unique constraint
테이블은 기본적으로 7 개의 열 집합에 대해 고유 한 제약 조건이 필요한 NOT NULL INTEGERS (일부 중간 INT 일부 작음) 컬렉션입니다 (테이블의 열이 더 많음) 이것은 매우 비쌉니다. 삽입 당 계산하고 인덱스 파일 크기를 훨씬 더 증가시킵니다. 그걸로 검색 할 수 없기 때문에 나는 그것을 삭제하고 어떻게 든 md5/어쩌면 단순한 concat 값을 ... 선호합니다. 아직 알지 못합니다.
문제는이 큰 고유 번호를 보유 할 수있는 유일한 열 유형은 varchar입니다.이 PK가 실제로 더 좋을지는 의문입니다. 내가 PRIMARY KEY 'part_key'(site_id, id)를 갖기 때문에 은 파티션 설계의 고유 한 제약 조건을 받아 들여야 만합니다 ... 이것이 새로운 문제는 아니지만 두 벤치 마크/문서를 비교할 수 없었습니다.이 문제에 대한 경험이있는 사람이 있습니까? 질문은 진짜 PK가 전체 필드가 될 것입니다 (이 테이블에는 아마도 100M 이상의 행이있을 것입니다). 고유 필드의 pk 또는 단지 해시 값을 검색하지 않을 때 추신 : 검색 중 주로 7 열 중 2 열을 수행합니다 디스크 크기는 문제가되지 않습니다 감사합니다.