새소식

🍹 [5분 내로] 강의실/✏️ 웹 개발자 5분 면접

[DBMS] varchar 칼럼 사이즈를 크게 잡으면 안되는 이유?

  • -
728x90

🤔 Question

👉 VARCHAR 데이터 타입에서 사이즈를 너무 크게 잡는 것은 다음과 같은 몇 가지 단점이 있습니다:

사이즈를 크게 잡는 것이 필요한 상황이라면, 아래의 내용을 고려하여 단점들을 피하는 것이 좋겠습니다.

 

🎯 메모리 및 스토리지 비효율성

👉 VARCHAR는 가변 길이 데이터 타입이라 실제로 저장된 데이터의 길이에 따라 스토리지가 할당되지만, 인덱스를 생성하거나 메모리에서 데이터를 처리할 때는 최대 길이를 고려합니다.

예를 들어, VARCHAR(1000)로 설정했는데 대부분의 데이터가 10~20자 정도라면, 메모리에서 쓸데없이 큰 공간을 차지할 수 있습니다.

 

🎯인덱스 성능 저하

👉 VARCHAR 컬럼에 인덱스를 걸 경우, 최대 길이를 기준으로 인덱스가 생성됩니다.

예를 들어, VARCHAR(5000) 컬럼에 인덱스를 생성하면 인덱스의 크기가 커지고, 조회 시 검색 성능이 떨어질 수 있습니다.

 

🎯 데이터 검증의 어려움

👉  VARCHAR의 길이를 너무 길게 설정하면, 예상보다 긴 데이터를 저장할 가능성이 커져 데이터 무결성 및 검증이 어려워질 수 있습니다. 실제로 필요한 길이에 맞게 크기를 설정하면, 실수로 너무 긴 데이터가 저장되는 것을 방지할 수 있습니다.

 

🎯 잠재적인 성능 문제

👉 일부 데이터베이스 엔진은 VARCHAR 컬럼의 크기에 따라 내부 처리 방식을 달리합니다.

예를 들어, MySQL의 경우 VARCHAR가 너무 크면 임시 테이블 생성 시 디스크 기반 테이블로 처리될 가능성이 높아져 성능 저하를 초래할 수 있습니다.

 

🎯 미래의 관리 문제

👉 너무 큰 값을 허용해 놓으면, 이후에 다른 개발자나 팀이 이를 사용하면서 실제 필요 이상의 데이터 크기를 기대하거나, 컬럼 길이에 대한 명확한 기준이 없어질 수 있습니다. 이는 데이터 구조 설계에서 혼란을 초래할 수 있습니다.

 

🎯 권장 사항

👉 실제 데이터의 길이를 분석하여 적절한 최대 크기를 설정하세요.

👉 정말로 긴 데이터가 필요한 경우에는 TEXT나 CLOB 같은 별도의 데이터 타입을 고려하세요.

👉 데이터 무결성과 성능을 유지하기 위해 필요한 만큼만 설정하는 것이 중요합니다.

 

예시: 이름 저장 컬럼이라면 VARCHAR(50) 정도로 충분하지만, 사용자 리뷰나 긴 텍스트라면 TEXT를 사용하는 것이 더 적합합니다.

If I was of any help to you, please buy me coffee 😿😢😥

If you have any questions, please leave them in the comments

🧭 References

[1] reference : https://doctorson0309.tistory.com/

[2] Ads : https://play.google.com/store/apps/details?id=io.cordova.seoulfilter

반응형
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.