포스트

카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지

Tech Blog Review
게시
By August
좋아요 조회 8 분 읽는 시간

원문: MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석 — kakao tech, 2025-10-17

한 줄 요약

DATETIME은 연월일시분초를 5바이트 정수로 묶어 부호 오프셋을 더해 저장하고(정렬 순서가 시간 순서와 같게), TIMESTAMP는 세션 타임존으로 UTC로 바꿔 32비트 정수로 저장한다. 소수 초는 선언 자릿수에 따라 0~3바이트가 붙는다. 이 32비트 때문에 TIMESTAMP는 2038-01-19 03:14:07 UTC를 넘는 값을 넣으면 오버플로로 초기화되고, 원문은 8.4.5에서 이를 재현했다. unix_timestamp() 반환은 8.0.28에서 64비트로 고쳐졌지만 컬럼 타입은 9.4 코드까지도 안 고쳐졌고 Oracle의 대응 계획은 미정이다. 선택 기준은 둘: 타임존 변환이 필요한가, 저장 범위가 문제인가.

DATETIME 저장 구조

소수 초(fsp) 도입 이후 정수부와 소수부를 나눠 저장한다.

정수부 5바이트. YYYY-MM-DD hh:mm:ss를 5바이트 바이너리로 변환하고, 3바이트 소수부와 합쳐 64비트 packed longlong을 만든 뒤, 상위 40비트만 추출하고, 오프셋 0x8000000000을 더한다. 예로 2023-07-01 12:34:56은 0x19b702c8b8이고 오프셋을 더하면 0x99b702c8b8이다.

소수부. 선언 자릿수에 따라 크기가 다르다.

fsp크기정밀도
00B초
1, 21B10⁻²
3, 42B10⁻⁴
5, 63B10⁻⁶

123456은 0x01e240. 그래서 2023-07-01 12:34:56.123456은 99 b7 02 c8 b8 01 e2 40 8바이트다. DATETIME(n)은 5~8바이트.

오프셋이 왜 필요한가. 정수부는 원래 부호 있는 40비트인데 디스크에는 부호 없는 5바이트로 저장된다. 오프셋을 더하면 부호 있는 범위(−2³⁹ ~ 2³⁹−1)가 부호 없는 범위(0 ~ 2⁴⁰−1)로 매핑되어 바이너리 정렬 순서가 시간 순서와 일치한다. 인덱스, 정렬, 비교 연산이 바이트 비교만으로 정확해지는 이유다.

TIMESTAMP 저장 구조

타임존 정보를 반영하는 타입이다. 세션 타임존 기준으로 입력값을 UTC로 바꿔 저장하고, 읽을 때 다시 세션 타임존으로 바꾼다. 입력 문자열은 str_to_datetime()으로 MYSQL_TIME 구조체에, 소수 초는 my_timeval 구조체(Windows처럼 tv_sec이 32비트인 플랫폼에서도 64비트를 담기 위한 MySQL 자체 구조체)에 넣는다.

UTC+9에서 2023-07-01 12:34:56.123456을 넣으면 MYSQL_TIME을 UTC로 변환해 4바이트로, 소수부 3바이트로, 총 7바이트다. TIMESTAMP(n)은 4~7바이트.

기능 비교

  • 자동 초기화·갱신: 둘 다 DEFAULT CURRENT_TIMESTAMP [ON UPDATE CURRENT_TIMESTAMP]. 소수 초를 쓰려면 CURRENT_TIMESTAMP(6)처럼 자릿수를 맞춰야 한다.
  • explicit_defaults_for_timestamp: TIMESTAMP에만 적용되고 “기본값을 안 적었을 때”의 동작을 정한다. OFF면 NULL 여부 미지정 시 NOT NULL이 되고, 첫 TIMESTAMP 컬럼에는 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP가 자동으로 붙으며, 나머지는 '0000-00-00 00:00:00'이 된다(STRICT 모드나 NO_ZERO_DATE와 충돌 가능). ON이면 NULL 허용이 기본이고 자동 속성이 안 붙는다. 오래전부터 deprecated 예정이고 되면 ON으로 고정되니, 영향받지 않게 컬럼 선언에 기본값과 NULL 여부를 명시하는 습관을 권한다.
  • 비표준 날짜: ALLOW_INVALID_DATES(월 1~12, 일 1~31만 검사, DATETIME만), NO_ZERO_IN_DATE(월/일 0 불허, 0000-00-00으로 변환 후 경고), NO_ZERO_DATE(0000-00-00에 경고). 뒤의 둘은 deprecated 예정.

Y2K38: 재현

2038-01-19 03:14:07 UTC를 넘으면 32비트 timestamp가 넘친다. OS는 64비트로 갔지만 소프트웨어는 아직이다. MySQL은 8.0.28에서 unix_timestamp()류 함수의 반환을 64비트로 고쳤다. 실제로 8.4.5에서 unix_timestamp('2038-01-19 03:14:08')은 정상 값을 준다.

그런데 테이블에 datetime 컬럼과 timestamp 컬럼을 두고 그 시각을 넘는 값을 INSERT하면, TIMESTAMP 컬럼만 오버플로로 초기화된다. 함수는 고쳤지만 컬럼은 여전히 32비트로 최대 2,147,483,647까지만 저장한다. 원문은 9.4 코드까지 확인해 미수정임을 확인했고, Oracle에 문의했으나 “미정”이었다.

선택 가이드

두 타입의 차이는 범위와 타임존 반영 여부다. 그래서 질문은 둘이다. 타임존 정보를 같이 다뤄야 하는 정보인가(그러면 TIMESTAMP), 저장 범위(2038)가 영향을 주는가(그러면 DATETIME). 예전에는 기본값 동작까지 차이가 컸지만 이제 사용성 차이는 작고, Y2K38이 해결되면 저장 크기 차이도 줄 것이라고 본다.

읽고 남는 질문

  • 13년 남았다는 것은 “만료일이 2038년 이후인 계약·구독·인증서”를 지금 TIMESTAMP에 넣는 시스템이 이미 문제라는 뜻이다. 그런 컬럼을 찾아내는 실무 점검법(information_schema 조회 + 값 분포 확인)이 있으면 좋겠다.
  • TIMESTAMP → DATETIME 전환 시 타임존 변환이 사라지므로 애플리케이션이 UTC로 쓰고 있었는지 세션 타임존으로 쓰고 있었는지에 따라 값이 9시간 어긋난다. 전환 절차가 별도 글로 있으면 유용하다.
  • 오프셋 트릭은 DATETIME 정렬의 근거인데, TIMESTAMP는 UTC 정수 자체가 단조 증가라 오프셋이 필요 없다는 대비를 한 줄 넣었으면 두 구조의 차이가 더 선명했을 것이다.

한 줄로 가져가기

TIMESTAMP는 “타임존을 대신 계산해 주는 4바이트 정수”이고 그 4바이트가 2038년에 끝난다. 함수는 고쳐졌지만 컬럼은 아니므로, 미래 날짜를 담는 컬럼은 지금 DATETIME인지 확인할 때다.

시리즈

빅테크 기술 블로그 리뷰

31편 중 3편

이전 시리즈 글 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다 다음 시리즈 글 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
TechBlog, Kakao
Tech Blog Review Kakao MySQL DATETIME TIMESTAMP Y2K38 Time Zone Database
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다