외래 키를 추가하는 DDL이 실패했는지, 이미 있는 외래 키 아래에서 INSERT가 실패했는지 먼저 나눕니다. 첫 경우는 타입·인덱스·엔진 같은 정의 조건을, 두 번째 경우는 참조할 부모 행의 존재와 실제 입력값을 봐야 합니다.
SHOW CREATE TABLE components;
SHOW CREATE TABLE component_checks;예시 테이블 이름을 실제 대상으로 바꿔, ORM 모델 대신 DB의 현재 정의를 비교합니다. MySQL 8.4 외래 키 조건은 정수 같은 고정 정밀도 타입의 크기와 부호를 맞추도록 합니다. 문자열 길이가 언제나 동일해야 한다는 일반화는 틀리며 문자열에서는 문자 집합·collation 같은 별도 조건을 봐야 합니다.
세 스키마 조합의 판단
설명용으로 부모가 INT UNSIGNED인데 자식이 BIGINT UNSIGNED이면 정수 크기가 다릅니다. 부모 INT UNSIGNED와 자식 INT는 부호가 다릅니다. 양쪽이 INT UNSIGNED로 맞아도 참조 인덱스·스토리지 엔진·기존 데이터의 조건이 남습니다. 따라서 타입을 맞췄다는 사실 하나로 제약 생성 성공을 보장하지 않습니다.
수정 방향은 기존 ID 범위와 앞으로 필요한 범위를 근거로 정합니다. 큰 자식 타입을 무조건 줄이면 기존 값이 넘칠 수 있고, 부모 타입을 늘리면 다른 참조 테이블·인덱스와 변경 잠금 비용이 따라옵니다. foreign_key_checks를 끄는 것은 타입 계약을 맞추는 해결책이 아닙니다.
스테이징에서 백업·복원 절차를 확인한 뒤 DDL과 유효·무효 참조 입력을 각각 시험하고 새 SHOW CREATE TABLE과 마이그레이션 기록을 보관합니다. 이 글은 문서와 예시 정의의 분석이며 운영 DB에서 ALTER를 실행하지 않았습니다.