잘못된 상식이구요

varchar2가 무조건 char보다 유리합니다.(최악의 경우 동등합니다.)

그러므로 혼선을 피하시고 무조건 varchar2 쓰십시오.

고정길이도 char 쓰지 마시고 varchar2 쓰십시오.

제가 이렇게 말씀 드리는 것은.

저는 어지간해서는 단정적으로 말씀을 안 드리지만 정말로 char는 구시대 유물일 뿐입니다.

char(5) 이라는 컬럼이 있는 경우 DB에 5자리만 잡히지 않습니다.

실제 데이타의 길이에 따라 1~3의 오버헤드가 있습니다. varchar2와 동일하게 말입니다.

oracle 서버는 저장 이미지 측면에서 char와 varchar2가 동일 합니다.

단 논리적 측면에서 및 물리적 측면에서 고정길이 만큼 패딩합니다.

사실은 제가 이 문제는 좀 한이 맺힌 것이 있어서 오기가 생겨서 실제 오라클 데이타 파일을 헥사 덤프하면서 확인한 내용이니까 절대적으로 믿으셔도 됩니다.

넵 감사합니다 *^^*

좋은 하루 되세요~

전에 제가 몇번 올린 자료가 있을겁니다.

char의 경우 스페이스가 패딩되는 만큼 추가적인 Scan 오버헤드를 유발하므로 실제 성능에서도 손해라는 것을 SQL Trace 증명한 자료가 검색해보시면 있을겁니다. (단위 면적당 밀집도가 떨어지므로...)

위의 경우 varchar2(1)과 char(1)은 사실 차이가 없습니다. 하지만 그래도 varchar2(1)을 쓰라고 하는건 많은 혼란과 문제점을 사전 예방하기 위함입니다.

전에 방문한 사이트에서 조인시 결과값이 나오지 않는다고 해서 살펴보니 조인 키 컬럼이 한쪽이 Varchar2고 다른 쪽은 Char더군요. Char쪽에 Space가 부족한 만큼 패딩되니까... 비교시 다르게 취급되어서 결과값이 나오지 않는 것이었습니다. 이 경우 trim()등으로 공백을 잘라내는 경우가 많은데 조인의 방향을 고정하여 성능에 악영향을 주는 경우를 튜닝해보신 분들은 최소한 한번 이상은 경험하시더군요.

(그 사이트의 경우도 원래는 고정폭 코드 칼럼이어서 char로 했는데 나중에 업무가 변해서 코드의 길이가 달라짐으로써 잘돌던 애플리케이션에 문제가 발생한 것입니다. 이처럼 업무 성격은 언제든지 변화할 수 있기 때문에 varchar2를 애초에 썼더라면 저런 문제는 발생치 않았겠지요.)

앞으로 char는 절대 쓰지 마시기 바랍니다.