이 기사에서는 데이터 로딩 작업의 효율성을 향상시키기 위한 MySQL의 전략을 소개합니다. SELECT 쿼리는 가장 일반적으로 사용되는 쿼리이기 때문에 최적화에 관심을 갖는 경우가 많으며 이를 최적화하는 방법을 결정하는 것이 항상 간단한 것은 아닙니다. 데이터베이스에 데이터를 로드하는 것은 비교적 간단합니다. SELECT 쿼리는 가장 일반적으로 사용되는 쿼리이기 때문에 최적화에 관심을 갖는 경우가 많으며 이를 최적화하는 방법을 결정하는 것이 항상 간단한 것은 아닙니다. 데이터베이스에 데이터를 로드하는 것은 비교적 간단합니다. 그러나 데이터 로딩 작업의 효율성을 향상시키는 데 사용할 수 있는 전략이 있으며 그 기본 원칙은 다음과 같습니다.
대량 로드는 단일 행 로드보다 빠릅니다. 각 레코드가 로드된 후 인덱스 캐시를 플러시할 필요가 없으며 레코드 배치가 로드된 후에 플러시될 수 있기 때문입니다.
인덱스 없이 테이블을 로드하는 것이 인덱스 이후에 로드하는 것보다 빠릅니다. 인덱스가 있는 경우 데이터 파일에 레코드를 추가해야 할 뿐만 아니라 새 레코드 추가를 반영하도록 각 인덱스를 수정해야 합니다.
짧은 SQL 문은 서버 측 분석이 덜 필요하고 클라이언트에서 서버로 네트워크를 통해 전송하는 속도가 더 빠르기 때문에 긴 SQL 문보다 빠릅니다. 이러한 요소 중 일부(특히 마지막 요소)는 사소해 보일 수 있지만, 많은 양의 데이터를 로드하는 경우 작은 요소라도 결과에 큰 차이를 만들 수 있습니다. 위의 일반 원칙을 사용하여 데이터를 가장 빠르게 로드하는 방법에 대한 몇 가지 실용적인 결론을 도출할 수 있습니다.
LOAD DATA(모든 형태)는 행을 일괄적으로 로드하므로 INSERT보다 더 효율적입니다. 인덱스 새로 고침 횟수가 적고 서버는 여러 명령문 대신 하나의 명령문만 구문 분석하고 해석하면 됩니다.
LOAD DATA는 LOAD DATA LOCAL보다 더 효율적입니다. LOAD DATA를 사용하면 파일이 서버에 있어야 하고 FILE 권한이 있어야 하지만 서버는 디스크에서 직접 파일을 읽을 수 있습니다. LOAD DATA LOCAL을 사용하면 클라이언트가 파일을 읽고 네트워크를 통해 서버로 전송하는데 속도가 느립니다.
INSERT를 사용해야 하는 경우 다음과 같이 단일 문에 여러 행을 지정할 수 있는 형식을 사용해야 합니다.
명령문에 지정할 수 있는 행이 많을수록 좋습니다. 이렇게 하면 필요한 명령문 수가 줄어들고 인덱스 새로 고침 횟수도 줄어듭니다. mysqldump를 사용하여 데이터베이스 백업 파일을 생성하는 경우 덤프 파일에 여러 줄의 INSERT 문이 포함되도록 --extended-insert 옵션을 사용해야 합니다. --extended-insert 옵션을 활성화하는 --opt(최적화)를 사용할 수도 있습니다. 반대로, mysqldump에 --complete-insert 옵션을 사용하는 것은 피해야 합니다. 이 옵션을 사용하면 INSERT 문이 한 줄로 실행되고 --complete-insert 옵션 없이 생성된 문보다 더 많은 분석이 필요하게 됩니다.
압축된 클라이언트/서버 프로토콜을 사용하여 네트워크 데이터 트래픽을 줄입니다. 대부분의 MySQL 클라이언트의 경우 --compress 명령줄 옵션을 사용하여 이를 지정할 수 있습니다. 압축에는 많은 프로세서 시간이 필요하기 때문에 일반적으로 느린 네트워크에서만 사용됩니다.
MySQL이 기본값을 삽입하도록 하세요. 어떤 방식으로든 기본값이 할당될 INSERT 문에 열을 지정하지 마세요. 평균적으로 이로 인해 명령문이 짧아지고 네트워크를 통해 서버로 전송되는 문자 수가 줄어듭니다. 또한 더 적은 수의 값을 포함하는 문에는 서버의 분석 및 변환이 덜 필요합니다.
테이블이 인덱싱된 경우 대량 삽입(LOAD DATA 또는 다중 행 INSERT 문)을 사용하여 인덱스 오버헤드를 줄일 수 있습니다. 이렇게 하면 각 행 이후가 아니라 모든 행이 처리될 때만 인덱스를 새로 고치면 되므로 인덱스 업데이트의 영향이 최소화됩니다.
새 테이블에 많은 양의 데이터를 로드해야 하는 경우 테이블을 생성하여 인덱스가 없을 때 로드한 다음 데이터를 로드한 후 인덱스를 생성하는 것이 더 빠릅니다. 행당 한 번씩 수정하는 대신 인덱스를 한 번 생성하는 것이 더 빠릅니다.
로드하기 전에 인덱스를 삭제하거나 비활성화한 경우 데이터를 로드한 후 인덱스를 다시 생성하거나 활성화하면 로드 속도가 더 빨라질 수 있습니다. 데이터 로드에 삭제 또는 비활성화 전략을 사용하려면 몇 가지 실험을 수행하여 그만한 가치가 있는지 확인하십시오(소량의 데이터를 큰 테이블에 로드하는 경우 재구축 및 인덱싱이 로드보다 오래 걸릴 수 있음). 데이터)).
DROP INDEX 및 CREATE INDEX를 사용하여 인덱스를 삭제하고 다시 작성할 수 있습니다. 대안은 myisamchk 또는 isamchk를 사용하여 인덱스를 비활성화하고 활성화하는 것입니다. 이를 위해서는 테이블 파일에 대한 쓰기 액세스 권한이 있는 MySQL 서버 호스트의 계정이 필요합니다. 테이블 인덱스를 비활성화하려면 해당 데이터베이스 디렉터리를 입력하고 다음 명령 중 하나를 실행합니다.
확장자가 .MYI인 인덱스 파일이 있는 MyISAM 테이블에는 myisamchk를 사용하고, 확장자가 .ISM인 인덱스 파일이 있는 ISAM 테이블에는 isamchk를 사용합니다. 테이블에 데이터를 로드한 후 다음과 같이 인덱스를 활성화합니다.
인덱스 비활성화 및 활성화를 사용하기로 결정한 경우 서버가 동시에 잠금을 변경하는 것을 방지하기 위해 13장에서 설명하는 테이블 복구 잠금 프로토콜을 사용해야 합니다(이때 테이블이 복구되지는 않지만 테이블처럼 수정됩니다) 복구 프로세스가 있으므로 동일한 잠금 프로토콜을 사용해야 합니다).
위에서 설명한 데이터 로드 원칙은 다양한 작업을 수행해야 하는 클라이언트와 관련된 고정 쿼리에도 적용됩니다. 예를 들어, 일반적으로 자주 업데이트되는 테이블에서 긴 SELECT 쿼리를 실행하지 않으려고 합니다. 장기 실행 SELECT 쿼리는 많은 경합을 발생시키고 작성기 성능을 저하시킬 수 있습니다. 한 가지 가능한 해결책은 먼저 임시 테이블에 레코드를 저장한 다음 쓰기가 주로 INSERT 작업인 경우 주기적으로 기본 테이블에 레코드를 추가하는 것입니다. 새로운 기록에 즉시 접근해야 하는 경우 이는 실현 가능한 접근 방식이 아닙니다. 하지만 이 방법은 짧은 시간 동안 접속하지 않는 한 사용할 수 있습니다. 임시 테이블을 사용하면 두 가지 이점이 있습니다. 첫째, 기본 테이블의 SELECT 쿼리 문과의 경합이 줄어들어 실행 속도가 빨라집니다. 둘째, 임시 테이블에서 기본 테이블로 레코드를 로드하는 데 걸리는 총 시간은 레코드를 별도로 로드하는 데 걸리는 총 시간보다 적습니다. 해당 인덱스 캐시는 각 행 이후가 아닌 각 일괄 로드가 끝날 때에만 새로 고쳐지면 됩니다. 짐. 이 전략의 한 가지 적용은 웹 서버의 웹 페이지에서 MySQL 데이터베이스에 액세스하는 것입니다. 이 시나리오에서는 레코드가 기본 테이블에 즉시 입력되도록 보장하는 더 높은 수준의 권한이 없을 수도 있습니다.
데이터가 시스템 종료 시 삽입되는 단일 레코드 종류가 아닌 경우 인덱스 새로 고침을 줄이는 또 다른 전략은 MyISAM 테이블에 DELAYED_KEY_WRITE 테이블 생성 옵션을 사용하는 것입니다(MySQL을 사용하는 경우 가능할 수 있음). 일부 데이터 입력 작업)이 발생합니다. 이 옵션을 사용하면 인덱스 캐시가 삽입할 때마다 새로 고쳐지는 것이 아니라 가끔씩만 새로 고쳐집니다.
서버 전체에서 지연된 인덱스 새로 고침을 활용하려면 --delayed-key-write 옵션을 사용하여 mysqld를 시작하면 됩니다. 이 시나리오에서는 다른 인덱스 값을 위한 공간을 확보하기 위해 블록을 플러시해야 할 때까지, 플러시 테이블 명령이 실행될 때까지 또는 인덱스 테이블이 닫힐 때까지 인덱스 블록 쓰기가 지연됩니다.
-