길거나 넓은 데이터베이스 테이블 디자인 (쿼리 성능면에서)이 더 효율적인 것은 무엇입니까?MySQL : 긴 테이블 대 넓은 테이블
즉,이
id S M L
1 12.4 23.1 33.3
2 3.3 5.3 11.0
대이
id size price
1 S 12.4
1 M 23.1
1 L 33.3
2 S 3.3
2 M 5.3
2 L 11.0
는 일반적으로 (나는 생각한다)는 아래 GROUP BY 사이의 성능 비교에 와서 직접 열을 선택 :
SELECT AVG(price) FROM table GROUP BY size
또는
SELECT AVG(S), AVG(M), AVG(L) FROM table
두 번째 글자는 글자를 쓰는 데 약간 더 길지만 (두 번째 글자는 글자 수가 많음) 두 글자의 성능은 어떨까요? 가능한 경우이 표 형식의 일반적인 장단점은 무엇입니까?
우선, 이들은 서로 다른 목적에 적합한 두 개의 서로 다른 데이터 모델입니다. 에
, 나는 데이터가 있으므로 적은 I/O를 필요로하는, 더 컴팩트하게 포장되어 있기 때문에 단순히 1 두 번째 모델은 빠른 통합을위한 것 기대 첫 번째 모델은 {size, price}의 전체 스캔으로 만족할 수 있습니다. 데이터가 너무 커서 RAM에 저장할 수 없을 때 인덱스 대신 사용할 수있는 옵션이 너무 느립니다.
첫 번째 방법은 table + index가 필요하고 두 번째 방법은 테이블 만 필요하므로 두 번째 경우에는 캐시 활용률이 더 좋습니다.캐싱을 무시하고 두 번째 모델의 테이블과 첫 번째 모델의 인덱스 (테이블 없음)를 비교하더라도 테이블이 실제로는 size을 기록하고 사용되지 않는 "구멍"이 있기 때문에 인덱스가 테이블보다 클 것으로 의심됩니다 B-Trees의 경우 (비록 이것이 clustered이라면 테이블에서도 마찬가지입니다).
마지막으로 두 번째 모델에는 INSERT/UPDATE/DELETE 성능에 영향을 줄 수있는 인덱스 유지 관리 오버 헤드가 없습니다.
이외의 경우 SUM 및 COUNT를 하나의 행만 포함 된 별도의 테이블에 캐싱하는 것을 고려할 수 있습니다. 주 테이블에서 행을 삽입, 업데이트 또는 삭제할 때마다 SUM 및 COUNT 트리거를 업데이트하십시오. 그러면 SUM과 COUNT를 나누어 현재 AVG를 쉽게 얻을 수 있습니다.
1
쿼리에 WHERE 절이 없으므로 모든 행이 검색됩니다. 인덱스는 테이블 행의 상대적으로 작은 하위 집합을 얻는 데에만 유용합니다 (때때로 index-only scans의 경우). 일반적으로 테이블의 행이 10 % 이상 필요한 경우 인덱스가 도움이되지 않으며 DBMS는 인덱스를 사용할 수있는 경우에도 전체 테이블 검색을 선택합니다.
길이가 더 유연합니다. 그것은 당신이
SELECT MAX(price) where size='L'
또한 그것은 size에와 id에 인덱싱 할 수 있습니다 예를
size에 필터링 할 수 있습니다. 그러면
GROUP BY과 다른 테이블이 결합 된 쿼리가
id 및/또는
size과 같은 제품 재고 테이블에 표시됩니다.
첫 번째 옵션은 더 많은 행을 생성하며 일반적으로 두 번째 옵션보다 느립니다.
그러나 Deltalima도 언급했듯이 첫 번째 옵션은 더 유연합니다. 다른 쿼리 옵션 일 때뿐만 아니라 다른 크기, 색상 등으로 테이블을 확장해야하는 경우/경우
매우 큰 데이터 세트가 있거나 매우 빠른 조회 시간이 필요하지 않으면 아마도 첫 번째 옵션으로 더 나을 것입니다.
매우 큰 데이터 세트가 있거나 필요한 경우 사전 계산 된 요약 값을 사용하여 테이블을 만드는 것이 좋습니다.
대단히 감사드립니다. 결국 귀하의 추가 의견은 매우 유용합니다, 내 질문은 내가 직면하고있는 큰 문제에 대한 간략한 요약이며, 나는 분명히이를 자세히 고려할 것입니다. – sashkello