mysql 에서 CHAR, VARCHAR 타입은 유사하다.

단지 저장하고 읽을 때만 살짝 다르다.

CHAR(40) 에 "mydata" 를 저장할 때, 6바이트를 저장하고 나머지 34바이트의 비어 있는 공간에는 공백을 채워서 저장한다.

그리고 읽어들일 때, 임의로 채워진 공백들은 제거되어서 읽혀진다. (물론, PAD_CHAR_TO_FULL_LENGTH 모드를 활성화하면 공백까지 다 읽어온다)

VARCHAR(40) 에 "mydata" 를 저장할 때, 6바이트를 저장하고, 뒤에 1바이트(255길이 미만) 또는 2바이트(255길이 이상)의 길이 정보를 추가한다.

따라서 VARCHAR 에는 공백을 채워넣지 않으므로, 가변 길이의 정보에 적합하다.

문제는 VARCHAR(40) 에 새로운 데이터가 업데이트 될 경우이다. 더 큰 길이의 데이터가 저장되면, 공간이 부족하여 새로운 저장 영역에 새로 할당해야 하기 때문이다. 이 때문에, 데이터 파편화가 심해진다.

테이블 ROW 중에 CHAR, VARCHAR 타입이 섞여 있으면 데이터 파편화는 발생할 수 밖에 없다. 파편화를 염두하고 설계한다면, 테이블의 데이터 타입 중에 VARCHAR 타입을 두어선 안될 것이다.

그러나 MySQL 에서는 다음의 쿼리를 적용하면 파편화를 막을 수 있다. 

 ALTER TABLE tblname ROW_FORMAT = FIXED;

VARCHAR 타입을 CHAR 타입처럼 동작하도록 강제로 지정하는 것이다. 덕분에 저장 용량은 증가하지만, VARCHAR 로 인한 파편화로 성능 저하는 막을 수 있다.

물론 VARCHAR 로 선언한다고 무조건 파편화가 발생하는 것은 아니다. 앞서서 적은대로, 처음에 데이터를 INSERT 한 뒤에, 다른 크기의 데이터로 UPDATE 가 발생할 경우에 파편화가 발생하는 것이다.

그러므로 LOG 테이블처럼 INSERT 만 허용되는 테이블에는 이 문제가 적용되지 않을 것이다.

그리고, 다음의 쿼리를 통해서 저장된 데이터를 분석해볼 수도 있다.

 SELECT * FROM tblname PROCEDURE ANALYSE();

마지막으로, 테이블 설계할 때부터 데이터 타입은 신중하게 고려하면 좋다. IPv4 문자열 주소는 CHAR(15) 형태로 한다든가, 아니면 아예 INT 값으로 저장할 수도 있다.(IPv6 라면 CHAR(39) 이다.)

그리고 MD5 암호키 정보는 CHAR(32) 형태로 하는 것이다.

http://netmaid.tistory.com/44