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

🤔 Question

👉 CHAR 데이터 타입에서 사이즈를 너무 크게 잡는 것은 여러 가지 이유로 비효율적이고 문제가 될 수 있습니다.

주요 이유만 딱딱 정리해보겠습니다.

 

🎯 고정된 메모리 사용으로 인한 스토리지 낭비

👉 CHAR는 고정 길이(fixed-length) 데이터 타입이기 때문에, 실제 데이터 길이에 관계없이 정의된 크기만큼 항상 공간을 차지합니다. 예: CHAR(100)로 설정했는데 저장하는 데이터가 "hello"(5자)라면, 나머지 95자에 대해 공백(Padding)이 추가되고, 디스크에 저장될 때도 100자로 처리됩니다. 결과적으로 짧은 데이터가 많을수록 스토리지 낭비가 커집니다.

 

🎯 메모리 비효율성

👉 CHAR 컬럼에 인덱스를 생성하면, 인덱스는 고정된 크기만큼 공간을 차지합니다.
예: CHAR(255)와 VARCHAR(255) 컬럼에 동일한 데이터가 저장될 경우, CHAR는 항상 최대 크기를 인덱스에 반영하기 때문에 인덱스 크기가 불필요하게 커집니다.

 

🎯 유연성 부족

👉 CHAR는 고정된 길이로 설계되어, 실제 데이터 크기가 다양할 경우 비효율적입니다. 데이터가 길이에 따라 변동이 크다면, VARCHAR처럼 가변 길이 타입이 더 적합합니다.

 

🎯 쿼리 성능 저하

👉 데이터가 고정된 크기로 저장되므로 읽기 및 쓰기 작업에서 더 많은 데이터를 처리해야 할 수 있습니다. 특히 네트워크를 통해 데이터를 전송하거나 디스크 I/O가 발생할 때, 불필요한 공백까지 처리해야 하므로 성능 저하를 유발합니다.

 

🎯 공백 제거 문제

👉 CHAR는 저장 시 데이터 길이를 고정하기 위해 공백(Padding)을 추가합니다. 하지만 일부 데이터베이스는 검색 시 공백을 제거하지 않고 처리할 수 있어, 예상치 못한 결과를 초래할 수 있습니다.
예: 'abc '와 'abc'가 서로 다르게 처리될 수 있습니다.

 

🎯 CHAR를 사용해야 하는 경우

👉 CHAR는 고정 길이 데이터에 적합합니다. 예를 들어:
우편번호 (예: CHAR(5) 또는 CHAR(9))
국가 코드 (예: CHAR(2) → ISO 3166-1 Alpha-2)
전화 지역 번호 등.

 

🎯 CHAR를 사용해야 하는 경우

👉 CHAR는 고정 길이 데이터에 적합합니다. 예를 들어:
우편번호 (예: CHAR(5) 또는 CHAR(9))
국가 코드 (예: CHAR(2) → ISO 3166-1 Alpha-2)
전화 지역 번호 등.

 

☔ 권장 사항

👉 데이터의 길이가 가변적인 경우, VARCHAR를 사용하는 것이 더 효율적입니다.
반드시 고정 길이가 필요한 경우에만 CHAR를 사용하고, 필요한 최소 크기를 설정하세요.

 

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

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

Buy me a coffee

▶ Youtube Sub

🧭 References

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

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