비교할 문제
대량 INSERT에서 확인할 질문은 한 행씩 INSERT와 multi-row batch는 어느 크기에서 처리량과 lock 비용이 균형을 이루는가입니다. 같은 unique 제약, transaction 원자성, 부분 실패와 retry 계약을 적용합니다. 결과값, 순서, 오류 처리와 부수 효과가 다르면 같은 성능 비교가 아닙니다. 먼저 두 후보가 같은 일을 하는지 작은 입력으로 확인합니다.
원인 분석과 재현
multi-row·COPY 같은 batch는 round trip을 줄이지만 transaction log, packet, lock 시간과 실패 시 rollback 범위를 함께 조정해야 합니다.
batch 1·100·1,000행, payload 100B·10KB, 동시 writer 1·20에서 왕복, commit, redo/binlog, lock과 packet을 봅니다. runtime version, 운영체제, CPU와 memory 제한도 결과와 함께 기록합니다. 이 예제의 plan과 문법은 MariaDB 기준이며 다른 DB 제품의 결과로 일반화하지 않습니다.
비교 질문은 한 행씩 INSERT와 multi-row batch는 어느 크기에서 처리량과 lock 비용이 균형을 이루는가입니다.
| 후보 | 유리한 조건 | 함께 치르는 비용 |
|---|---|---|
| row-by-row autocommit | 작고 독립적인 드문 쓰기 | network·fsync 왕복이 행마다 반복 |
| multi-row batch | 같은 transaction의 대량 입력 | packet·lock·rollback 단위가 커짐 |
| loader/COPY 계열 | 검증된 대규모 적재 | 제품별 문법, 권한과 별도 오류 처리 |
START TRANSACTION;
INSERT INTO events (event_key, payload) VALUES
('event-1', '{"ok":true}'),
('event-2', '{"ok":true}'),
('event-3', '{"ok":true}');
ROLLBACK; -- 검증 run은 운영 데이터를 남기지 않습니다.
-- 1·100·1,000행 batch를 client에서 반복해 왕복, packet, lock과 redo/binlog 양을 함께 기록합니다.
해결 방안과 판정
warm-up과 측정 구간을 나누고 여러 번 반복합니다. 서비스 지연은 median과 p95를, 처리량 비교는 단위 시간당 완료 수와 오류율을 함께 기록합니다. CPU time, allocation, RSS·heap, GC, I/O 중 이 작업에 직접 관련된 지표만 선택합니다. 가장 큰 batch가 항상 좋은 것은 아닙니다. packet, transaction log, lock 유지 시간과 재시도 비용이 급증하기 전의 폭을 부하 테스트로 정합니다.
차이가 반복 실행의 흔들림보다 작다면 더 단순하고 읽기 쉬운 구현을 선택합니다. 차이가 충분히 크더라도 실제 요청 전체의 지연과 자원 사용이 개선되는지 확인한 뒤 적용합니다.
공식 문서와 적용 범위
문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 DB 제품과 version, schema·index·통계 상태, 데이터 분포와 동시 부하에서 다시 확인합니다.