UUID를 저장하다 Data too long이 나면 “UUID는 36자”라는 설명만으로 컬럼을 늘리지 마세요. 앱이 보내는 값이 하이픈 포함 문자열인지, 32자리 hex인지, 16바이트 바이너리인지와 컬럼의 저장 계약을 먼저 맞춰야 합니다.
from uuid import UUID
u = UUID("12345678-1234-5678-9abc-123456789abc")
print(len(str(u)), len(u.hex), len(u.bytes))
print(UUID(bytes=u.bytes) == u)Python 3.12.3에서 실제 출력은 36 32 16과 True였습니다. 이 결과는 표현 길이와 Python의 왕복 변환을 확인합니다. 문자열 16자와 바이너리 16바이트가 같다는 뜻은 아니며, MySQL 드라이버가 어떤 타입으로 bind하는지는 따로 확인해야 합니다.
DB 제품과 변환 함수를 섞지 않기
MySQL의 UUID_TO_BIN·BIN_TO_UUID는 저장·복원 변환을 제공합니다. swap 옵션을 사용한다면 양쪽 변환의 옵션 계약도 같아야 합니다. MariaDB UUID 타입은 MariaDB 10.7부터 제공되는 별도 기능이므로 MySQL 예제를 그대로 호환 기능처럼 설명할 수 없습니다.
길이를 바꾸기 전에 작은 입력 행렬 만들기
버전, SHOW CREATE TABLE의 실제 정의, 드라이버 bind 타입을 확보하고 정상 UUID·잘못된 문자열·NULL의 기대 동작을 정합니다. 예를 들어 CHAR(32)에 str(u)를 보내는 조합은 표현 계약부터 어긋납니다. 반면 BINARY(16)에 hex 문자열을 그대로 넣는 조합은 길이만 줄이는 것으로 해결되지 않습니다.
스테이징에서 입력→저장→조회→역변환이 원래 UUID와 같은지 확인하고, 기존 데이터·외래 키·인덱스·잠금 시간을 평가한 뒤 마이그레이션을 설계합니다. strict mode를 끄거나 문자열을 잘라 넣으면 오류가 숨겨지고 식별자가 달라질 수 있습니다. 이번 실험은 실제 DB의 삽입·DDL 성공을 확인한 결과가 아닙니다.