목차
I. 서론: MySQL 데이터 적재 방법론 비교 분석
A. 고성능 데이터 적재의 중요성 및 접근법
데이터 엔지니어링 파이프라인에서 CSV 파일과 같은 벌크(Bulk) 데이터를 관계형 데이터베이스에 효율적으로 적재하는 것은 시스템 성능과 운영 효율성에 직접적인 영향을 미칩니다. 일반적으로 INSERT 문을 사용하여 행 단위로 데이터를 삽입하는 방식은 트랜잭션 오버헤드가 누적되어 대용량 데이터 처리에는 비효율적입니다. 따라서, MySQL은 대량의 텍스트 파일을 처리하기 위해 최적화된 내부 명령어를 제공하며, 이는 적재 과정(ETL Load Phase)의 속도를 결정하는 핵심 요소가 됩니다.
B. 주요 CSV 적재 방법론 비교 분석
MySQL 환경에서 CSV 데이터를 적재하는 방법은 크게 명령줄 기반(CLI) 방식과 그래픽 사용자 인터페이스(GUI) 방식으로 나눌 수 있습니다. 이 중 LOAD DATA INFILE 명령은 텍스트 파일의 행을 직접 읽어 데이터베이스 테이블에 삽입하도록 설계되어, 특히 대규모 CSV 파일 적재에 최적화된 고성능 방식입니다.
mysqlimport 유틸리티 또한 내부적으로 LOAD DATA INFILE 명령을 활용하여 데이터를 적재하는 프로그램으로, 스크립트 기반 자동화에 유용합니다. 이 유틸리티는 MySQL 5.1.7 버전부터 –use-threads 옵션을 통해 병렬 로드 기능을 지원하여 성능을 더욱 향상시켰습니다.
반면, MySQL Workbench, phpMyAdmin 등의 GUI 기반 도구들은 사용자 친화적인 마법사 형태의 인터페이스를 제공하지만, 대용량 데이터 적재 시에는 성능이 크게 저하됩니다. 이는 GUI 도구가 내부적으로 행별 INSERT 문을 사용하거나, 파일 내용을 클라이언트에서 처리한 후 네트워크를 통해 서버로 전송하는 오버헤드 때문에 발생합니다.
대용량 데이터의 안정성과 성능이 요구되는 전문가 수준의 환경에서는, 적재 속도를 최대화하고 데이터 변환 과정을 정밀하게 제어할 수 있는 LOAD DATA INFILE 명령어 사용이 가장 권장되는 접근 방식입니다.
| 방법론 | 적합성 | 성능 지표 (대규모 데이터 기준) | 제어 및 구성 유연성 | 주요 제약사항 |
|---|---|---|---|---|
| LOAD DATA [LOCAL] INFILE | 대용량, 자동화, ETL 파이프라인 | 최상 (벌크 로딩 최적화) | 최상 (변환, 인덱스 제어 가능) | 서버/클라이언트 보안 설정 (local_infile) 요구, 초기 복잡도 높음 |
| mysqlimport Utility | 스크립트 기반 자동화 | 상 (LOAD DATA 기반) | 중 (구문 옵션 제한적) | 별도 유틸리티 실행 필요 |
| MySQL Workbench/phpMyAdmin | 소~중규모, 일회성 수동 작업 | 중하 (느림) | 하 (GUI 옵션에 종속됨) | 속도 저하, 세부 설정 제약, 복잡한 데이터 변환 불가 |
II. Phase 1: 선행 준비 및 데이터 무결성 확보
고성능 데이터 적재를 위해서는 CSV 파일 자체의 형식 표준화와 MySQL 대상 테이블의 구조 정의가 선행되어야 합니다.
A. CSV 파일 무결성 점검 및 형식 표준화
CSV 파일은 텍스트 기반이므로, MySQL이 파일 내용을 정확하게 파싱할 수 있도록 파일의 구조를 명확히 정의해야 합니다.
1. 구분자(Delimiter) 및 인용 부호 정의:
LOAD DATA INFILE 명령은 파일 내에서 각 필드(Field)를 구분하는 문자(TERMINATED BY)와 텍스트 값을 감싸는 문자(ENCLOSED BY)를 정확히 지정해야 합니다. 표준 CSV 파일은 쉼표(,)를 구분자로 사용하며, 필드 내에 구분자가 포함된 경우를 대비하여 이중 따옴표(“)를 인용 부호로 사용하는 것이 일반적입니다.
2. 줄 바꿈 문자(Line Terminator) 확인:
데이터베이스에 행(Row)의 끝을 알리는 줄 바꿈 문자(LINES TERMINATED BY)는 CSV 파일이 생성된 운영체제 환경에 따라 달라집니다. Windows 환경에서는 캐리지 리턴 및 라인 피드 조합인 \r\n이 사용되지만, Unix/Linux 환경 및 많은 표준 텍스트 파일에서는 라인 피드만(\n)이 사용됩니다. 적재 실패를 방지하려면 CSV 파일의 실제 종단 문자를 확인하여 명령 구문에 정확하게 지정해야 합니다.
B. MySQL 테이블 스키마 정의 (CREATE TABLE)
CSV 파일을 로드하기 전에, 데이터가 삽입될 대상 테이블의 구조를 정확하게 정의해야 합니다.
1. 최적의 데이터 타입 선택 및 수치형 데이터 관리:
CSV 파일에 포함된 수치형 데이터(예: 가격, 수량, ID)를 담기 위해 가장 효율적인 MySQL 데이터 타입을 선택하는 것이 중요합니다. 불필요하게 넓은 데이터 타입을 사용하는 것은 디스크 공간 낭비와 쿼리 성능 저하로 이어질 수 있습니다. 예를 들어, 큰 정수형 ID에는 BIGINT를, 소수점 이하 정밀도가 필요한 금액 데이터에는 DECIMAL(10, 2)와 같은 타입을 명시적으로 지정해야 합니다.
2. InnoDB 스토리지 엔진 사용 권장:
대규모 데이터 적재 시 트랜잭션의 안정성과 충돌 복구(Crash Recovery) 기능을 활용하기 위해서는 InnoDB 스토리지 엔진을 사용하는 것이 표준 권장사항입니다.
C. 문자 집합 및 인코딩 관리 (한국어 환경 특화)
한국어가 포함된 CSV 파일을 MySQL에 적재할 때 발생하는 가장 흔한 문제는 인코딩 불일치로 인한 한글 깨짐 현상입니다. 이 문제는 데이터 무결성을 심각하게 훼손할 수 있으므로, 로드 전에 반드시 처리해야 합니다.
일부 CSV 생성 도구(특히 엑셀)는 파일을 UTF-8로 저장할 때 파일 시작 부분에 BOM(Byte Order Mark)을 삽입합니다. 이 BOM은 MySQL이나 Linux 환경에서 보이지 않는 추가 문자로 해석되어 첫 번째 필드를 파싱하는 데 오류를 유발하거나 데이터 깨짐 현상의 원인이 될 수 있습니다.
이를 해결하기 위한 선제적 조치로, 모든 CSV 파일은 반드시 UTF-8 (BOM 없음) 형식으로 인코딩되어야 합니다. 파일이 메모장이나 전문 텍스트 편집기(예: Notepad++)에서 깨지지 않고 올바르게 표시되는지 확인하고, 만약 BOM이 의심되거나 인코딩이 불분명하다면 파일을 ANSI나 UTF-8 (BOM 없음) 형식으로 ‘다른 이름으로 저장’하여 표준화해야 합니다. 또한, LOAD DATA INFILE 구문 자체에 CHARACTER SET ‘utf8’ 옵션을 명시적으로 지정하여 인코딩 불일치 가능성을 최소화해야 합니다.
III. Phase 2: LOAD DATA INFILE 핵심 구문 및 작동 원리 심층 분석
LOAD DATA INFILE 명령은 파일 위치, 데이터 파싱 규칙, 그리고 데이터 변환 로직을 통합적으로 정의하는 강력한 SQL 구문입니다.
A. 기본 구문 구조 및 필수 옵션
LOAD DATA 구문은 다음 요소를 포함합니다:
LOAD DATA [LOCAL] INFILE 'file_name'
INTO TABLE tbl_name
[CHARACTER SET charset_name]
[FIELDS
[TERMINATED BY 'string']
[ENCLOSED BY 'char']
]
[LINES
[TERMINATED BY 'string']
]
[IGNORE number LINES]
[(col_name_or_user_var [,...])]
[SET col_name = expr [,...]]
대부분의 CSV 적재 작업에서 필수적인 옵션은 IGNORE number LINES입니다. CSV 파일에는 일반적으로 데이터를 설명하는 헤더 행이 포함되므로, 이를 데이터베이스에 삽입하지 않도록 IGNORE 1 LINES와 같이 지정해야 합니다.
B. Non-LOCAL vs. LOCAL INFILE: 경로, 성능, 보안 비교
LOAD DATA 명령에서 LOCAL 키워드의 포함 여부는 파일의 물리적 위치와 데이터 전송 방식, 그리고 보안 요구 사항을 결정하는 근본적인 차이를 만듭니다.
1. Non-LOCAL (LOAD DATA INFILE):
이 모드에서는 MySQL 서버 자체가 파일 시스템에 접근하여 데이터를 읽습니다. 따라서 파일은 MySQL 서버 호스트 내부에 위치해야 합니다. 서버가 파일을 직접 읽기 때문에 네트워크 전송 오버헤드가 없어 일반적으로 LOCAL 방식보다 더 빠른 성능을 보입니다. 그러나 이 방식을 사용하려면 사용자에게 FILE 권한이 부여되어야 하며, 파일의 위치는 MySQL 시스템 변수인 secure_file_priv가 지정하는 디렉터리 내로 제한됩니다.
2. LOCAL (LOAD DATA LOCAL INFILE):
이 모드에서는 클라이언트 호스트에 파일이 위치합니다. 클라이언트 프로그램이 파일을 읽고, 그 내용을 데이터베이스 연결을 통해 서버로 스트리밍합니다. 이 데이터 전송 과정 때문에 Non-LOCAL 방식보다 처리 속도가 약간 느릴 수 있습니다. 장점은 FILE 권한이 필요하지 않으며, 클라이언트가 접근 가능한 모든 경로의 파일을 사용할 수 있다는 점입니다. 단, 서버와 클라이언트 애플리케이션 모두 local_infile 설정을 명시적으로 허용해야만 작동합니다.
ETL 파이프라인과 같이 높은 성능과 일관된 보안 관리가 중요한 운영 환경에서는 파일을 서버에 스테이징한 후 Non-LOCAL 방식을 사용하여 secure_file_priv 경로를 통해 접근을 중앙에서 통제하는 것이 일반적인 권장사항입니다.
IV. Phase 3: 보안 환경 설정 및 권한 관리 (Critical Pre-configuration)
데이터 적재의 성공 여부는 MySQL 서버의 파일 접근 권한 및 보안 설정에 직접적으로 달려 있습니다.
A. 서버 및 클라이언트 local_infile 설정
LOAD DATA LOCAL INFILE 기능을 사용하려면 서버와 클라이언트 양쪽에서 로컬 파일 로딩 기능을 활성화해야 합니다. 만약 MySQL 서버(mysqld)가 local_infile 시스템 변수를 비활성화한 상태로 시작되었다면, LOCAL 명령 사용 시 오류가 발생합니다.
local_infile을 활성화하는 방법은 다음과 같습니다:
1. 서버 설정 (영구적): my.cnf 파일의 [mysqld] 섹션에 local-infile=1을 추가하고 서버를 재시작합니다.
2. 서버 설정 (런타임): 전역 변수를 변경하여 활성화합니다.
SET GLOBAL local_infile = ON;
3. 클라이언트 설정: MySQL 클라이언트 접속 시 –local-infile 옵션을 사용하여 연결해야 합니다.
mysql --local-infile -u your_username -p your_database_name
B. Non-LOCAL 사용 시 파일 접근 제어: secure_file_priv
LOAD DATA INFILE (Non-LOCAL) 모드는 서버의 파일 시스템에 직접 접근하므로, 보안을 위해 엄격하게 제어됩니다. 이 모드를 사용하기 위해서는 다음 두 가지 조건이 충족되어야 합니다:
1. FILE 권한: 명령을 실행하는 사용자에게는 파일을 읽을 수 있는 FILE 권한이 부여되어야 합니다.
2. secure_file_priv 제약: 파일이 서버 시스템 변수 secure_file_priv가 가리키는 디렉터리 내에 위치해야 합니다. 이 변수가 비어있는 경우(보안상 취약) 파일이 서버에서 읽기만 가능하면 되지만, 일반적으로 특정 보안 디렉터리를 지정하여 파일 접근을 통제합니다.
C. LOAD DATA LOCAL의 보안 취약점 분석 및 대책
LOAD DATA LOCAL 기능은 클라이언트가 지정한 파일을 서버가 요청하여 전송받는 구조입니다. 이로 인해 잠재적인 보안 위험이 발생할 수 있습니다. 특히 웹 환경에서 공격자가 SQL 서버에 임의의 명령을 실행할 수 있는 경우, LOAD DATA LOCAL을 악용하여 웹 서버 프로세스가 읽을 수 있는 로컬 파일을 읽어 들일 수 있습니다.
이러한 보안 위험을 최소화하고 최소 권한 원칙을 준수하기 위해, 데이터 엔지니어링 환경에서는 저장 프로시저(Stored Procedure)를 사용하는 방법을 고려할 수 있습니다. LOAD DATA INFILE 명령을 높은 권한을 가진 사용자(DEFINER)가 정의한 저장 프로시저 내에 캡슐화하고, 일반 사용자에게는 해당 프로시저의 EXECUTE 권한만 부여합니다. 이 방법은 전역적으로 local_infile을 활성화하거나 낮은 권한 사용자에게 FILE 권한을 부여하는 위험 없이, 특정 로직을 통해 안전하게 대규모 적재를 수행하도록 권한을 위임할 수 있게 합니다.
V. Phase 4: 고급 데이터 변환 및 무결성 확보 (User Variables and SET Clause)
CSV 파일의 데이터는 순수한 문자열이므로, 대상 테이블의 엄격한 데이터 타입 및 제약 조건을 만족시키기 위해서는 LOAD DATA INFILE 구문의 사용자 변수 (@variable)와 SET 절을 활용한 데이터 변환 및 정제 과정이 필수적입니다.
A. 사용자 변수 (@variable) 활용의 필요성
일반적으로는 CSV 파일의 컬럼 순서와 테이블 컬럼 이름을 구문 뒤에 나열하여 데이터를 직접 로드합니다. 그러나 다음 두 가지 경우에 해당하는 필드에 대해서는 반드시 @variable을 사용하여 임시로 값을 읽어야 합니다:
- CSV 필드에 저장된 값을 함수(예: 날짜 형식 변환, 조건부 처리)를 사용하여 가공해야 할 경우.
- 대상 테이블 컬럼에 DEFAULT 값이 설정되어 있지만, CSV 파일에서 제공하는 값을 명시적으로 사용하거나 해당 값을 변환하여 할당해야 할 경우.
데이터 적재 시 필드 목록에 @variable을 사용하면, 해당 필드의 원본 문자열 값이 변수에 저장되며, 이 변수는 SET 절에서 참조 및 처리될 수 있습니다.
B. SET 절을 이용한 날짜/시간 데이터 변환 심층 분석
CSV 파일에서 날짜 및 시간 데이터가 ‘YYYY-MM-DD’ 형식이 아닌 ‘MM/DD/YYYY’와 같은 다양한 비표준 문자열 형태로 존재할 때, MySQL의 DATETIME 또는 TIMESTAMP 타입에 정확히 맞추기 위해서는 데이터 변환이 필수적입니다.
SET 절은 사용자 변수에 저장된 값을 기반으로 변환 함수를 실행하고, 그 결과를 최종 테이블 컬럼에 할당합니다. 가장 중요한 변환 함수는 STR_TO_DATE()입니다.
예를 들어, CSV 파일에 날짜가 ’10/25/2023′ (%m/%e/%Y 형식)으로 저장되어 있고, 이를 TIMESTAMP 컬럼에 삽입해야 하는 경우, 다음과 같이 SET 절을 구성합니다:
LOAD DATA LOCAL INFILE 'file.csv'
...
(col1, col2, @csv_date_string) -- CSV의 날짜 필드를 @csv_date_string 변수로 읽음
SET target_date_column = STR_TO_DATE(@csv_date_string, '%m/%e/%Y');
더 나아가, TIMESTAMP 함수를 사용하여 변환된 날짜 값을 명시적으로 TIMESTAMP 타입으로 캐스팅할 수도 있습니다. 이러한 변환은 해당 컬럼에 DEFAULT current_timestamp와 같은 기본값이 설정되어 있더라도 CSV의 값을 강제로 삽입하기 위해 필수적인 과정입니다.
C. 수치형 데이터 및 NULL 값 처리 전략
수치형 데이터를 로드할 때 CSV 파일 내에 공백(”), 혹은 ‘N/A’와 같은 비표준 문자열이 존재하면, MySQL은 기본적으로 해당 필드를 0으로 처리하거나 엄격 모드에서 오류를 발생시킵니다. 데이터 무결성을 확보하기 위해, 이러한 값들은 SQL의 NULL로 명시적으로 처리되어야 합니다.
SET 절을 활용하면 로드 과정에서 데이터 정제(Data Cleaning) 기능을 내재화할 수 있습니다. NULLIF() 함수는 특정 문자열과 일치하는 경우 NULL을 반환하며, IF() 함수는 복잡한 조건부 매핑에 사용됩니다.
| CSV 데이터 형태 | MySQL 데이터 타입 | CSV 로드 변수 | SET 절 구문 예시 | 주요 목적 |
|---|---|---|---|---|
| 2023/10/25 (String) | DATE / TIMESTAMP | @csv_date | target_date = STR_TO_DATE(@csv_date, ‘%Y/%m/%d’) | 날짜 형식 변환 및 정규화 |
| Empty String (”) | INT / NULL | @csv_num | target_num = NULLIF(@csv_num, ”) | 빈 문자열을 SQL NULL로 매핑 |
| N/A or (missing) | DECIMAL / NULL | @csv_price | target_price = IF(@csv_price IN (‘N/A’, ‘(missing)’), NULL, @csv_price) | 비표준 문자열 NULL 처리 |
| Y or N (String) | BOOLEAN / TINYINT | @csv_bool | is_active = IF(@csv_bool = ‘Y’, 1, 0) | 불리언 값 매핑 및 숫자형 할당 |
VI. Phase 5: 대용량 적재를 위한 성능 최적화 전략 (ETL Tuning)
LOAD DATA INFILE 명령의 속도를 극대화하기 위해서는 MySQL 서버의 내부 제약 조건을 일시적으로 완화하는 튜닝 작업이 필요합니다. 이 최적화 전략은 주로 InnoDB 스토리지 엔진에 적용됩니다.
A. 인덱스 및 제약 조건의 사전 비활성화
데이터베이스에 대량의 행이 삽입될 때, 가장 큰 성능 저하 요인은 삽입되는 행마다 인덱스를 업데이트하고 외래 키(Foreign Key) 및 고유 키(Unique Key) 제약 조건을 검사하는 과정입니다.
1. 외래 키 검사 비활성화: 대량 적재 시 데이터 참조 무결성 검사를 생략하여 I/O 부하를 줄여야 합니다.
SET FOREIGN_KEY_CHECKS = 0;
2. 고유 제약 조건 검사 비활성화: unique_checks를 비활성화하면 고유 인덱스에 대한 삽입 시점의 검사를 생략하고, 로드 완료 후 일괄적으로 검사하게 하여 성능을 향상시킬 수 있습니다.
SET UNIQUE_CHECKS = 0;
3. 비-고유 인덱스 처리: 인덱스 업데이트 오버헤드를 줄이는 가장 효과적인 방법은 로드 전에 비-고유(Non-Unique) 인덱스를 잠시 제거(DROP)한 후, 데이터 로드가 완료된 다음 일괄적으로 다시 생성(CREATE)하는 것입니다. 이 방식은 개별 행 삽입 시 B-트리 업데이트 비용을 회피하여 속도를 극적으로 높일 수 있습니다.
B. 트랜잭션 관리 및 I/O 최소화
대규모 적재 작업은 단일 또는 최소한의 대규모 트랜잭션으로 처리되어야 디스크 I/O와 트랜잭션 로그 기록 횟수를 최소화할 수 있습니다.
1. AUTOCOMMIT 비활성화: LOAD DATA 명령 실행 전에 autocommit 모드를 비활성화하여 모든 삽입 작업을 하나의 큰 트랜잭션으로 묶습니다.
SET autocommit = 0;
작업 완료 후에는 반드시 명시적으로 COMMIT을 수행해야 합니다. (단, 수백 기가바이트를 초과하는 초대형 파일의 경우, 시스템 장애 발생 시 롤백 부담을 줄이기 위해 수십만 행 단위로 배치 커밋을 고려할 수 있습니다.)
2. 로그 버퍼 최적화: 서버 구성 파일에서 innodb_buffer_pool_size와 같은 InnoDB 관련 버퍼 설정을 데이터 적재 요구사항에 맞게 일시적으로 높여 메모리 사용을 최적화하고 디스크 I/O를 줄이는 것도 성능 향상에 기여할 수 있습니다.
C. 통합 성능 최적화 시퀀스 (로드 스크립트 흐름)
전문적인 대용량 데이터 적재 프로세스는 다음과 같은 명확하고 구조화된 순서를 따르며, 이는 성능 튜닝의 원칙을 반영합니다.
1. 전역 설정 조정 및 제약 조건 비활성화:
-- 트랜잭션 및 검사 일시 중지
SET autocommit = 0;
SET unique_checks = 0;
SET foreign_key_checks = 0;
-- (옵션) 비-고유 인덱스 제거
-- ALTER TABLE target_table DROP INDEX index_name;
2. 데이터 적재 실행 (벌크 로드):
LOAD DATA [LOCAL] INFILE '/path/to/file.csv'
INTO TABLE target_table
CHARACTER SET 'utf8'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(col1, col2, @var_date, @var_price)
SET date_column = STR_TO_DATE(@var_date, '%Y-%m-%d'),
price_column = NULLIF(@var_price, '');
3. 트랜잭션 커밋 및 인덱스 재활성화:
-- 트랜잭션 완료
COMMIT;
-- 제약 조건 및 자동 커밋 원상 복구
SET foreign_key_checks = 1;
SET unique_checks = 1;
SET autocommit = 1;
-- (옵션) 제거했던 인덱스 재생성
-- ALTER TABLE target_table ADD INDEX index_name (column_name);
VII. 결론 및 종합 점검 체크리스트
A. 고성능 ETL 프로세스의 핵심 요약
CSV 파일을 MySQL 데이터베이스에 적재하는 것은 단순한 데이터 이동 작업이 아니라, 파일 무결성 검사, MySQL 서버 보안 구성, 데이터 변환 로직 적용, 그리고 성능 최적화가 결합된 정밀한 데이터 엔지니어링 프로세스입니다. LOAD DATA INFILE 명령은 다른 GUI 기반 도구들(MySQL Workbench 등)에 비해 압도적인 성능을 제공하지만, 이를 효율적으로 사용하기 위해서는 파일 인코딩, 서버 보안 설정(local_infile, secure_file_priv), 그리고 데이터 정제(SET 절)와 같은 복잡한 요구사항들을 완벽하게 관리해야 합니다.
성공적인 대용량 데이터 적재는 단순히 명령어를 실행하는 것을 넘어, 데이터의 무결성을 지키면서 서버 자원 사용을 최소화하는 튜닝 전략을 포함합니다.
B. 데이터 적재 성공을 위한 최종 체크리스트
| 카테고리 | 점검 항목 | 조치/확인 사항 |
|---|---|---|
| 파일 전처리 | 인코딩 형식 | UTF-8 (BOM 없음)으로 통일되었는가? |
| 구분자 정의 | 쉼표(,), 줄바꿈 문자(\n 또는 \r\n)가 CSV 파일과 정확히 일치하는가? | |
| 테이블 정의 | 스키마 일치 | CSV 컬럼 순서와 테이블 정의가 일치하는가? |
| 스토리지 엔진 | InnoDB 엔진을 사용하였는가? | |
| 보안/경로 설정 | LOCAL 사용 여부 | LOAD DATA LOCAL INFILE 사용 시, 클라이언트와 서버 양쪽에서 local_infile=ON인가? |
| Non-LOCAL 사용 여부 | 파일이 서버 secure_file_priv 디렉터리에 위치하며 FILE 권한이 있는가? | |
| 데이터 변환 | SET 절 활용 | 날짜 형식 변환(STR_TO_DATE) 및 NULLIF를 이용한 데이터 정제 로직이 구현되었는가? |
| 성능 최적화 | 제약 조건 | 로드 전 FOREIGN_KEY_CHECKS=0 및 UNIQUE_CHECKS=0 설정이 적용되었는가? |
| 트랜잭션 | 로드 전 autocommit=0 설정 후, 로드 완료 후 COMMIT 및 제약 조건 원상 복구가 수행되었는가? |
참고 자료
- How to Import CSV into MySQL – OneSchema
- MySQL 8.4 Reference Manual :: 15.2.9 LOAD DATA Statement
- MySQL LOAD DATA – 컴퓨터 엔지니어로 살아남기
- How to Import CSV File into MySQL Table in 5 Different Ways – Skyvia Blog
- MySQL workbench table data import wizard extremely slow – Stack Overflow
- Why loading data with MySQL Workbench is so slow? – Georgi Sotirov’s Blog
- Import data in MySQL from a CSV file using LOAD DATA INFILE – Stack Overflow
- Best practices for importing and exporting data | Cloud SQL for MySQL – Google Cloud
- [DBeaver]CSV파일로 export시 한글 깨짐 현상 해결 방법 – 코딩 시그널
- UTF8 및 한글 블록 현상 해결 방안 – dBack
- MySQL 8.4 Reference Manual :: 15.2.9 LOAD DATA Statement
- MySQL: Enable LOAD DATA LOCAL INFILE – Stack Overflow
- 8.1.6 Security Considerations for LOAD DATA LOCAL – MySQL :: Developer Zone
- Securing LOAD DATA LOCAL – Database Administrators Stack Exchange
- Solved: Bulk Load Into Mysql DB Using Load Data Infile | Experts Exchange
