테이블에 열이 너무 많으면 성능이 저하됩니까?

테이블에 열이 너무 많으면 성능이 저하됩니까?

데이터의 총량이 증가하는 것 외에도 테이블에 많은 열이 있는 경우 성능 비용이 발생합니까?그렇다면 테이블을 몇 개의 작은 테이블로 나누는 것이 상황에 도움이 될까요?

나는 30개의 칼럼에서 나쁜 코드 냄새가 난다는 이 모든 게시물에 동의하지 않습니다.30개 이상의 합법적인 속성을 가진 엔티티를 가진 시스템에서 일해본 적이 없다면 경험이 많지 않을 것입니다.

HLGEM이 제공한 답변은 사실 그 중에서 가장 좋은 답변입니다.저는 특히 "자주 사용하는 것과 자주 사용하지 않는 것 중에 자연스러운 분열이 있는가"라는 그의 질문이 마음에 듭니다. 스스로에게 물어보는 것은 매우 좋은 질문이고, 여러분은 자연스러운 방식으로 테이블을 해체할 수 있을지도 모릅니다(상황이 통제할 수 없게 되면).

현재 귀사의 성능이 만족스럽다면 필요한 경우가 아니면 솔루션을 재창조할 생각을 하지 마십시오.

당신이 이미 답을 선택했음에도 불구하고 나는 이것을 고려할 것입니다.예, 너무 넓은 테이블은 성능 문제(및 데이터 문제)를 일으킬 수 있으므로 일대일 관계를 가진 테이블로 분리해야 합니다.이는 데이터베이스가 데이터를 저장하는 방식 때문입니다(적어도 SQL Server에서는 MySQL에 대해 잘 모르지만 데이터베이스가 데이터를 저장하고 액세스하는 방법에 대한 설명서를 읽을 가치가 있습니다).

30개의 열은 너무 넓거나 그렇지 않을 수 있습니다. 열의 너비에 따라 다릅니다.30개 열이 차지할 총 바이트 수를 더하면 레코드에 저장할 수 있는 최대 바이트 수보다 넓습니까?

필요한 열이 다른 열보다 적은 경우(즉, 필요한 정보와 자주 사용되는 정보 및 다른 모든 위치에 표시되지 않는 한 위치에만 표시되는 기타 항목 간에 자연스럽게 분할됨), 표를 분할하는 것을 고려해 보십시오.

일부 열이 phone1, phone2, phone3과 같은 경우에는 열 수가 중요하지 않습니다. 대신 일대일 관계를 가진 관련 테이블이 필요합니다.

일반적으로 30개의 열은 비정상적으로 크지 않으며 아마 괜찮을 것입니다.

이러한 모든 열이 정말로 필요한 경우(즉, 테이블이 잘못 설계되었음을 나타내는 것만이 아님), 반드시 보관해야 합니다.

성능 문제가 아닙니다. 당신만 좋다면요.

• 행을 선택하는 데 사용해야 하는 열에 적절한 인덱스 사용
• SELECT 작업에 필요하지 않은 열을 검색하지 않음

30개 또는 200개의 열이 있으면 데이터베이스에 문제가 없습니다.한 번에 모든 열을 검색하려면 작업을 좀 더 어렵게 만드는 것뿐입니다.

하지만 많은 열을 갖는 것은 나쁜 코드 냄새입니다. 저는 잘 설계된 테이블이 이렇게 많은 열을 가질 수 있는 정당한 이유를 생각할 수 없습니다. 대신에 여러분은 훨씬 더 단순한 다른 테이블과의 일대일 관계가 필요할 수도 있습니다.

엄밀히 말하면, 30개의 칼럼은 절대적으로 괜찮습니다.그러나 많은 열이 있는 테이블은 데이터베이스가 제대로 정규화되지 않았음을 나타냅니다. 즉, 데이터베이스에 중복 및/또는 일관되지 않은 데이터가 포함될 수 있습니다.

제가 보기엔 30개가 너무 많은 것 같지는 않아요.필요한 인덱스와 적절한 SELECT 쿼리 외에도 와이드 테이블의 경우 다음 두 가지 기본 팁이 잘 적용됩니다.

1. 열을 가능한 한 작게 정의합니다.
2. 테이블당 열 수가 많은 경우 VARCHAR 또는 TEXT와 같은 동적 열을 최대한 사용하지 마십시오.CHAR와 같은 고정 길이 열을 사용해 보십시오.이는 디스크 스토리지를 성능과 맞바꾸기 위한 것입니다.

예를 들어 100개 이상의 열이 있는 '사람' 테이블의 '이름', '성별', '나이', '바이오' 열의 경우 성능을 극대화하기 위해 다음과 같이 정의하는 것이 가장 좋습니다.

1. 이름 - CHAR(70)
2. 성별 - TINYINT(1)
3. 연령 - TINYINT(2)
4. 생체 - 텍스트

이 방법은 가능한 한 작고 가능한 한 고정된 길이의 열을 정의하는 것입니다.동적 열은 고정 길이 열이 모두 앞에 오도록 테이블 구조의 끝에 있어야 합니다.

이로 인해 대량의 행으로 인해 엄청난 Disk 스토리지가 낭비된다는 것은 두말할 나위도 없지만, 성능을 원하는 만큼 그에 따른 비용이 발생할 것이라고 생각합니다.

다른 유용한 정보는 다른 열보다 훨씬 자주 사용(선택 또는 업데이트됨)되는 열을 찾을 때마다 다른 테이블로 분리하여 자주 사용하지 않는 열이 포함된 다른 테이블과 일대일 관계를 형성하고 관련된 열이 적은 쿼리를 수행해야 한다는 것입니다.

괜찮아요, 당신이 가지고 있지 않는 한.select * from yourHugeTable안가는 곳이 없어요.항상 필요한 열만 선택합니다.

일반적으로 30개의 열은 과도한 숫자로 간주되지 않습니다.

반면에 3천 개의 기둥은...매우 광범위한 "표"를 어떻게 구현하시겠습니까?

예를 들어 테이블이 일부 열만 공유하고 다른 열은 공유하지 않는 둘 이상의 애플리케이션을 제공하는 경우, 보고에 모두를 위한 실시간 단일 데이터 풀이 필요한 경우, 데이터 전환이 없는 경우 등과 같은 상황에 적합합니다.200개의 열 표가 그러한 분석력과 유연성을 가능하게 한다면, 저는 "계속"이라고 말할 것입니다.물론 대부분의 상황에서 정규화는 효율성을 제공하고 모범 사례이지만 필요에 따라 작업을 수행합니다.

성능 외에도 데이터베이스 정규화는 테이블과 관계가 너무 많은 데이터베이스에 필요합니다.정규화를 통해 모델에 쉽게 액세스할 수 있고 다양한 SQL 쿼리를 실행할 수 있는 유연한 관계를 얻을 수 있습니다.

여기에 나와 있는 것처럼 정규화에는 8가지 형태가 있습니다.그러나 많은 시스템의 경우 첫 번째, 두 번째, 세 번째 정규 양식을 적용하면 충분합니다.

따라서 관련 열을 선택하고 긴 sql 쿼리를 쓰는 대신 정규화된 데이터베이스 테이블이 더 좋습니다.

언급URL : https://stackoverflow.com/questions/3474865/is-there-a-performance-decrease-if-there-are-too-many-columns-in-a-table