MariaDB 날짜 형태를 저장할때 varchar 와 date 차이점

날짜타입은 varchar(X) date(O)

 

 

데이터베이스에서 테이블을 설계할 때 년월일의 데이터가 들어가는 항목들이 있을 때, 보통 칼럼 타입을 어떻게 생성하셨나요?~

 

개발한 지 얼마 안 됐을 때는 CHAR(8), VARCHAR(8)로 칼럼을 만들어서 20250116처럼 문자열로 들어가게 많이 했던 것 같습니다.

이제 와서 왜 그랬을까, 생각해 보면 내부 프레임워크에서 날짜 관련은 문자열로 많이 조작하기도 했었고,

기존에 테이블들이 다 CHAR(8)로 되어 있어서 관행에 따라 했던 것 같습니다.

 

개요

MariaDB에서 날짜 데이터를 VARCHAR(8)로 설계하는 것과 DATE 타입으로 설계하는 것에는 저장 방식, 성능, 기능 지원 등 여러 면에서 차이가 있습니다.

올바른 데이터 타입을 선택하는 것은 성능과 데이터 무결성 측면에서 매우 중요하니, 차이점을 참고해 보도록 하겠습니다.

 

1. 저장크기

VARCHAR(8)

• 한 글자당 1~3바이트(UTF-8 사용 시)
• 8글자 문자열은 8~24바이트를 차지
• 추가적으로 가변 길이 특성 때문에 1~2바이트의 길이 정보가 추가됨
• 결과적으로 최소 9바이트 이상 필요

DATE

• 고정 크기 3바이트만 사용
• 날짜 형식 (YYYY-MM-DD)을 내부적으로 숫자로 저장하므로 효율적

저장공간 측면에서 DATE가 훨씬 효율적

 

 

2. 데이터 무결성

VARCHAR(8)

• 날짜  형식을 문자열로 관리하므로, 잘못된 값 입력 가능
• 예로, "20230140" 존재하지 않은 날짜 또는 "abcd1234"와 같은 비정상 데이터가 저장될 수 있음
• 무결성을 유지하려면 애플리케이션에서 별도의 검증 로직 필요

DATE

• MariaDB가 유효한 날짜만 저장을 허용
• 입력값에 대해 자동으로 유효성을 검증하므로 잘못된 날짜 저장 방지

데이터 무결성 측면에서 DATE가 더 안전하고 신뢰성 있음

 

 

3. 성능

VARCHAR(8)

• 문자열 비교를 하므로 성능이 떨어짐.
• 날짜 비교 연산 시, 문자열의 사전순 비교로 처리되어 의도와 다른 결과가 발생할 가능성 있음
• 인덱스 크기가 커지고 검색 성능 저하

DATE

• 내부적으로 숫자 연산을 사용하여 비교 연산 속도가 빠름.
• 인덱스 크기도 작아져 검색 속도 향상.

성능 측면에서 DATE가 더 빠르고 효율적

 

 

4. 기능 지원

VARCHAR(8)

• 날짜 관련 내장 함수 (DATE_ADD, DATE_SUB, YEAR, MONTH 등)를 사용할 수 없음.
• 문자열을 DATE로 변환 (STR_TO_DATE()) 후 처리해야 함.

 

DATE

• 내장 함수와 연산을 바로 사용할 수 있어 편리함.
• 날짜 형식 출력도 자유롭게 변환 가능 (DATE_FORMAT()).

기능 지원 측면에서 DATE가 훨씬 우수함.

 

 

5. 사용 사례

VARCHAR(8) 사용을 고려할 경우

• 아주 드물게, 날짜가 아닌 단순 문자열로 사용해야 하는 특수 상황.
• 예: 날짜 형식처럼 보이는 코드값이나 식별자(단, 이 경우에도 다른 데이터 타입이 더 적합할 가능성 높음).

DATE 사용을 권장할 경우

• 날짜 데이터를 저장, 검색, 비교하거나 날짜 계산이 필요한 경우.
• 데이터 무결성과 효율성을 중요하게 여기는 대부분의 상황.

 

6. 실제 테이블 크기 비교

실제로 두개의 테이블을 만들어서 테이블 저장 공간과 인덱스를 생성했을 때의 저장 공간을 비교해 보겠습니다.

그럼, 한 개의 테이블은 VARCHAR(8)로, 또 한 개는 DATE로 인덱스를 추가 후 100만 개씩 데이터를 입력해 보겠습니다.

CREATE TABLE date_to_varchar
(
    ORDER_DATE      VARCHAR(8),
    ORDER_NO        VARCHAR(100),
    KEY IDX_date_to_varchar_01 (ORDER_DATE)
);

CREATE TABLE date_to_date
(
    ORDER_DATE      DATE,
    ORDER_NO        VARCHAR(100),
    KEY IDX_date_to_date_01 (ORDER_DATE)
);

 

테이블과 인덱스를 생성하였다.

그럼 100만 개의 데이터를 등록해 보겠습니다.

INSERT INTO date_to_varchar
SELECT
    DATE_FORMAT(DATE_ADD('19900101', INTERVAL seq DAY), '%Y%m%d'),
    UUID()
FROM seq_1_to_1000000;

INSERT INTO date_to_date
SELECT
    DATE_ADD('19900101', INTERVAL seq DAY),
    UUID()
FROM seq_1_to_1000000;

 

쿼리로 테이블 크기 확인하기

MariaDB에서는 각 테이블의 저장 정보를 information_schema.TABLE에서 확인할 수 있습니다.

SELECT
    TABLE_NAME,
    DATA_LENGTH,      -- 실제 데이터 크기
    INDEX_LENGTH,     -- 인덱스 크기
    DATA_LENGTH + INDEX_LENGTH AS TOTAL_SIZE,  -- 총 크기
    TABLE_ROWS        -- 테이블의 행 수
FROM information_schema.TABLES
WHERE
    TABLE_SCHEMA = 'my_database'
    AND TABLE_NAME IN ('date_to_varchar', 'date_to_date');

 

테이블 저장 크기 비교

 

쿼리를 실행하면 실제 데이터 크기, 인덱스 크기, 총크기를 확인할 수 있습니다.

DATE 타입으로 생성한 테이블이 VARCHAR(8) 타입으로 생성한 테이블보다 작은 크기인 것을 확인할 수 있습니다.

 

파일 시스템에서 확인하기

MariaDB 데이터 디렉터리에서 실제 디스크에서 차지하는 공간을 확인해 보겠습니다.

 

데이터 디렉터리는 아래의 명령어로 경로를 확인할 수 있습니다.

SHOW VARIABLES LIKE 'datadir';

데이터 디렉토리 위치 확인

 

MariaDB 해당 데이터베이스 디렉터리로 이동해서 두 테이블의 크기 차이를 확인할 수 있습니다.

 

실제 파일도 당연하지만, DATE로 생성한 테이블 크기가 더 작은 걸 확인할 수 있습니다.

 

7. 결론

DATE 타입은 저장 효율성, 성능, 데이터 무결성, 기능 지원 모든 면에서 VARCHAR(8) 보다 뛰어납니다.
VARCHAR(8)는 특별한 이유가 없는 한 날짜 데이터를 저장하는 데 적합하지 않습니다.

 

따라서 날짜 데이터를 저장할 때는 반드시 DATE 타입을 사용하는 것이 권장됩니다.