MySQL 테이블 정의에 대한 성능 제안

Question

데이터베이스 테이블의 성능과 관련이 있습니다. 고객 설문 조사 응용 프로그램과 관련된 데이터를 저장해야합니다.

설문 조사의 고객 응답을 저장하는 데이터베이스 테이블이 있습니다.

partkey : 인 부분의 단축 코드 (설문 조사 질문은 고객에 따라 변화하기 때문에

customerdata(customerid varchar, 
     partkey varchar, 
     questionkey varchar, 
     value, varchar, 
     version, int, 
     lastupdate, timestamp) 

을 다음과 같이 내가 대신 열 각 questionid을 사용하여 테이블 스키마를 정의하는 경우를 정의 할 수 있지만 일부 고객은 두 번 조사를 채우기 때문에 질문의 단축 코드가 예를 들어, 나이, 성별 등

는, 세 번 내가 추가 한 등입니다 : questionkey이 PART1, 2 부 ...)

버전 열.

이 디자인 고객 ID에서는 partkey, questionkey 및 version이 기본 키입니다.

나는 이러한 디자인의 성능에 대해 우려하고 있습니다. 다른 기본 키를 인덱스로 정의해야합니까? 그게 도움이 되겠습니까? 지금까지 30 명의 고객에게 7000 개의 레코드가 있습니다. 나는 최대 300-500을 가질 것으로 예상한다. 어떻게 생각해 ?

Answer 1

아주 작은 데이터베이스처럼 들립니다. 성능 문제는 의심 스럽지만 나중에 partkey, questionkey 또는 version을 쿼리 할 때 하나 이상의 인덱스를 추가하여 그 시간에 문제를 해결할 수 있습니다. 자신이 가지고 있지 않은 성능 문제를 해결할 필요는 없으며 아마도 없을 것입니다.

customerid 필드를 기본 필터로 사용하지 않는 시간에 민감한 쿼리를 수행해야하는 경우에만 성능 문제가 발생합니다. 나는 당신이 그런 질문을 할 것이라고 생각한다. (고객을 가로 질러 데이터를 집계하고 싶을 때), 나는 그런 것들을 볼 때 기대할 수있는 1 초 또는 그 이하의 응답 시간만큼 영향을받을만큼 충분히 시간에 민감 할 것이다. 작은 데이터 수집. 그렇다면 색인을 추가하십시오.

또한 테이블에는 단일 PRIMARY KEY 만 있습니다. 이 키는 둘 이상의 열을 사용할 수 있으므로 customerid, partkey, questionkey 및 version은 부분이 인 PRIMARY KEY이지만 모두 "기본 키"라고 말할 수는 있습니다.

Answer 2

rownumber-wise, 나는 100000 개가 넘는 행이있는 mysql 데이터베이스를 경험했으며 괜찮습니다.

이지만 복잡한 쿼리를 실행하면 행 번호가 아닌 데이터베이스 디자인에 더 의존하는 경우가 다릅니다.