MySQL의 INSERT IGNORE는 중복 외 오류도 무시: 11가지 대상 오류와 안전한 대체 방법

INSERT IGNORE는 '중복된 행만 건너뛰는' 구문이 아닙니다.

중복만 건너뛰고 싶다면, 다음과 같이 작성해야 합니다.

INSERT INTO t (...) VALUES (...) 
ON DUPLICATE KEY UPDATE id = id;

AI(Claude Code)에게 특정 DB의 로그를 1시간마다 별도의 DB로 추가 복사하는 처리를 작성하게 했습니다. 원본 로그는 오래된 행부터 덮어쓰여 사라지기 때문에, 그 전에 사본을 남기기 위함이었습니다.

누락 방지를 위해 이전보다 약간 앞쪽부터 다시 읽어오기 때문에, 중복은 매번 발생합니다. 사본 테이블에 유니크 키를 설정하고, 중복된 분은 버리는 설계로 이 코드가 나왔습니다.

INSERT IGNORE INTO log_copy (source_id, event_type, logged_at, status)
VALUES (?, ?, ?, ?);

적용하기 전에 Codex로 검토한 결과,

설정해 두었더라도 경고는 예외가 아니므로, 이 확인은 별도로 필요합니다.

INSERT INTO log_copy (source_id, event_type, logged_at, status)
VALUES (?, ?, ?, ?)
ON DUPLICATE KEY UPDATE id = id;

중복일 때는 아무것도 변경하지 않고, 그 외의 오류는 평소대로 발생합니다. 다만 다음 3가지를 확인해 주세요.

affected rows의 의미: 신규 삽입=1, 업데이트=2, 동치 업데이트=0. id = id의 중복은 0이 됩니다 (CLIENT_FOUND_ROWS 지정 시 1).
유니크 키가 여러 개인 테이블: 어떤 키로 충돌했는지에 따라 업데이트 대상이 달라지므로, 공식 문서도 일반적으로 피해야 한다고 합니다.
AUTO_INCREMENT 소비: InnoDB 기본 설정에서는 삽입되지 않았더라도 번호가 진행될 수 있습니다 (IGNORE도 마찬가지).

직접 구성한 고정값을 넣는 것만으로, NULL이나 범위 외가 발생할 리 없다고 단언할 수 있는 경우는 문제가 없습니다.

외부 데이터나 타 시스템의 테이블을 복사하는 처리에서는 피하는 것이 안전합니다. 원본 측에서 컬럼 정의가 바뀌어도, IGNORE를 포함한 처리는 조용히 값을 반올림하여 성공으로 간주하게 됩니다.

판단 기준은 하나입니다. '이 INSERT가 중복 이외의 이유로 실패했을 때, 멈춰야 하는가?' 만약 멈춰야 한다면 ON DUPLICATE KEY UPDATE를 사용해야 합니다.

이 글은 AI(Claude Code)에게 데이터베이스의 정기 복사 처리를 작성하게 하는 과정에서 얻은 내용을 정리한 것입니다. 같은 일을 AI 측면에서 작성한 것이 '쿠지라'와 'AI와'에 있습니다.

요약