인프런 커뮤니티 질문&답변
작성한 질문수
실제 프로젝트에서의 데이터 타입 환경
해결된 질문
작성
·
328
2
안녕하세요.
강의 잘 보고 있습니다.(너무 감사합니다.)
일단 char와 varchar에 대해서는 저는 이전부터 고민이 많았는데요. 이번 강의를 보면서 기존 인터넷에서 보던 자료와 상충하는 내용이 발생하여 질문을 드리고 싶습니다.(물론 '누구의 자료가 잘못됐다'라는 것이 아니라 초보자인 제 입장에서 정말 궁금해서 질문을 드린다는 말씀을 드리고 싶습니다!)
사실 내용을 여럿 찾아봤는데 결과적으로 char를 써야 할 경우 TRIM을 통해 공백을 지워야 하기 때문에 그러한 연산이 더 들어가므로 varchar를 쓰는 것이 귀찮음도 없고 좋다라는 글을 보았던 것 같습니다.(백엔드 개발자의 입장에서도 편리하다고 생각합니다.)
하지만 varchar를 쓸 경우 말씀해주신 것처럼 데이터의 길이가 기존보다 클 경우 기존 데이터를 삭제하고 새로 옮겨야 하는 비효율적인 작업이 증가할 뿐더러 데이터 페이지의 파편화가 발생할 수 있다는 생각도 정말 충분히 납득이 가는 설명이었습니다.
실제로 웬만해서는 char보다는 varchar를 쓰는 편일까요? 아니면 trim의 연산을 하는 것을 감안하고 char를 쓰는 편일까요?
답변 1
3
안녕하세요.
답변드린다는 것을 깜빡하고 있었네요. 죄송해요.
사실 내용을 여럿 찾아봤는데 결과적으로 char를 써야 할 경우 TRIM을 통해 공백을 지워야 하기 때문에 그러한 연산이 더 들어가므로 varchar를 쓰는 것이 귀찮음도 없고 좋다라는 글을 보았던 것 같습니다.(백엔드 개발자의 입장에서도 편리하다고 생각합니다.)
아래 2개 비용을 비교해서 말씀을 하셨는데, 사실 1번과 2번은 작업 내용상 비용 비교가 될 수 있는 수준이 아닙니다. 정확하게 수치로 말씀드리긴 어렵지만, 대략 예를 든다면, 1번 작업이 마이크로 초 단위의 작업이라면 2번 작업은 밀리초 단위의 작업이 될 가능성이 높습니다.
CHAR(*) 타입 컬럼의 값을 TRIM()으로 공백을 지우는 비용
파편화로 인한 공간 낭비 및 Row-migration(변경시 레코드 이동) 비용
그리고 MySQL 서버에서는 CHAR 타입과 VARCHAR 타입 모두 MySQL 서버에서 문자열 뒤쪽의 Space는 기본 Trim하고 Client로 내려 보내기 때문에 (옵션에 따라 다를 수 있지만, 기본 작동 방식 기준으로), AppServer에서 space trim 작업을 별도로 하실 필요가 없습니다.
실제로 웬만해서는 char보다는 varchar를 쓰는 편일까요? 아니면 trim의 연산을 하는 것을 감안하고 char를 쓰는 편일까요?
이미 말씀드렸듯이, TRIM 연산 비용보다는 CHAR로 인한 공간 낭비가 VARCHAR의 Fragmentation 대비 효율적이라는 근거만 있다면, CHAR 타입을 사용하는 것이 좋아 보입니다.
말씀해주셔서 감사합니다!
조금 더 공부해 보지 않은 제 문제인 거 같아서 부끄럽네요!
궁금한 점에 대해서 시원하게 말씀해주셔서 정말 감사합니다!