■ MySQL to MySQL 복제방법MySQL을 소스로 사용하여 MySQL 타겟으로 복제를 진행하는 방법을 알아봅니다.이 방법은1. On-premise에서 AWS RDS로 복제하거나2. AWS RDS에서 AWS RDS로 복제하거나3. AWS RDS에서 On-premise로 복제하는 방식에 사용됩니다. ■ 계정 및 권한 설정1. 복제 유저.개인적으로 권장사항은 사용할수만 있다면 관라자 권한, 즉 On-premise에서는 root, RSD에서는 Master username 권하고 싶습니다.이 유저를 이용하면 최고관리자의 권한이기 때문에 모든 기능이 가능하며 별도 권한 설정도 필요없습니다.하지만 내부의 보안 정책상 관리자 권한은 사용할 수 없고 별도의 계정으로 생성을 하고 그 유저를 이용해서 복제를 해야 한..
SAVEPOINT identifierROLLBACK [WORK] TO [SAVEPOINT] identifierRELEASE SAVEPOINT identifier InnoDB는 SQL 문 SAVEPOINT, ROLLBACK TO SAVEPOINT, RELEASE SAVEPOINT 및 ROLLBACK에 대한 선택적 WORK 키워드를 지원합니다. SAVEPOINT문은 이름이 식별자여서 이름이 지정된 트랜잭션 세이브포인트을 설정합니다. 현재 트랜잭션에 이름이 같은 저장점(savepoint)이 있으면 이전 저장점이 삭제되고 새 세이브포인트가 설정됩니다. ROLLBACK TO SAVEPOINT 문은 트랜잭션을 종료하지 않고 트랜잭션을 이름이 지정된 세이브포인트로 롤백합니다. 세이브포인트가 설정된 후 행에 수행 된 ..
파티션을 재구성할시 보통 REORGANIZE PARTITION을 자주 사용합니다.이때 몇가지 유의해야 할 사항이 있습니다. 바로 MAXVALUE 파티션 유무에 따른 재구성입니다. ■ 예제 테이블CREATE TABLE dbadm.part_table_test ( `id` int(10) unsigned NOT NULL, `sec_id` int(10) unsigned NOT NULL, `target_date` datetime NOT NULL, PRIMARY KEY (id,target_date)) ENGINE=InnoDB DEFAULT CHARSET=utf8/*!50500 PARTITION BY RANGE COLUMNS(target_date)(PARTITION part201912 VALUES LESS T..
트랜잭션 문법은 다음과 같습니다.START TRANSACTION [transaction_characteristic [, transaction_characteristic] ...]transaction_characteristic: { WITH CONSISTENT SNAPSHOT | READ WRITE | READ ONLY}BEGIN [WORK]COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]SET autocommit = {0 | 1} 이 문법은 트랜잭션 사용에 대한 제어를 제공합니다 :+ START TRANSACTION 또는 BEGIN 문법으로 새로운 트랜잭션을 시작합니다.+ C..
■ 파티셔닝에 대한 제한 사항이 글에서는 MySQL 파티셔닝 지원에 대한 현재 제한 사항에 대해 설명합니다. ▶︎ 금지된 문법.파티셔닝 표현식에서는 다음 구성이 허용되지 않습니다.저장 프로 시저, 저장 함수, UDF 또는 플러그인선언된 변수 또는 사용자 변수 ▶︎ 산술 및 논리 연산자.산술 연산자 +,-및 *는 파티셔닝 표현식에서 사용할 수 있습니다. 그러나 결과는 정수값 또는 NULL이어야합니다([LINEAR] KEY 파티셔닝의 경우 제외).DIV 연산자도 지원되며/연산자는 허용되지 않습니다.비트 연산자 |, &, ^, > 및 ~는 파티셔닝 표현식에서 허용되지 않습니다. ▶︎ HANDLER 문법.이전에는 HANDLER문이 파티션된 테이블에서 지원되지 않았습니다. 이 제한은 MySQL 5.7.1부터 제거..
■ 파티션 선택MySQL 5.7은 명령문을 실행할때 주어진 WHERE 조건과 일치하는 행을 검사해야하는 파티션 및 하위 파티션의 명시적 선택을 지원합니다. 파티션 선택은 특정 파티션 만 일치하는지 검사하지만 두 가지 주요 측면에서 다르다는 점에서 파티션 정리와 유사합니다.1. 점검할 파티션은 파티션 프루닝과 달리 자동으로 명령문을 발행하여 지정합니다.2. 파티션 프루닝은 쿼리에만 적용되는 반면, 파티션의 명시적 선택은 쿼리와 다수의 DML문 모두에 대해 지원됩니다. 명시적 파티션 선택을 지원하는 SQL 문은 다음과 같습니다.1. SELECT2. DELETE3. INSERT4. REPLACE5. UPDATE6. LOAD DATA.7. LOAD XML. 이 절의 나머지 부분에서는 방금 나열된 명령문에 적용되..
이 섹션에서는 파티션 정리(Partition 라고하는 최적화에 대해 설명합니다. 파티션 정리의 기본 개념은 비교적 간단하며“일치하는 값이 없는 파티션은 스캔하지 않습니다”라고 설명 할 수 있습니다. 이 명령문으로 정의된 파티션 된 테이블 t1이 있습니다.CREATE TABLE t1 ( fname VARCHAR(50) NOT NULL, lname VARCHAR(50) NOT NULL, region_code TINYINT UNSIGNED NOT NULL, dob DATE NOT NULL)PARTITION BY RANGE( region_code ) ( PARTITION p0 VALUES LESS THAN (64), PARTITION p1 VALUES LESS THAN (128)..
■ 파티션 관리MySQL 5.7은 분할된 테이블을 수정하는 여러 가지 방법을 제공합니다. 기존 파티션을 추가, 삭제, 재정의, 병합 또는 분할할 수 있습니다. 이러한 모든 조치는 ALTER TABLE 문에 대한 파티션 확장을 사용하여 수행 할 수 있습니다. 파티션된 테이블 및 파티션에 대한 정보를 얻는 방법도 있습니다. 다음 섹션에서 이러한 주제에 대해 설명합니다. 노트MySQL 5.7에서 파티션된 테이블의 모든 파티션은 같은 수의 서브 파티션을 가져야하며 테이블이 생성되면 서브 파티션을 변경할 수 없습니다. 테이블의 파티셔닝 구성표를 변경하려면 partition_options절과 함께 ALTER TABLE문만 사용해야 합니다. 이 절은 파티션된 테이블을 작성하기 위해 CREATE TABLE에서 사용된것..
■ 파티셔닝 타입이 섹션에서는 MySQL 5.7에서 사용할 수있는 파티셔닝 유형에 대해 설명합니다. 여기에 나열된 유형이 포함됩니다.+ RANGE 파티셔닝.이 유형의 파티셔닝은 주어진 범위 내에 속하는 열 값을 기반으로 파티션에 행을 할당합니다. 22.2.1 절“RANGE 파티션”을 참조하십시오. 이 유형의 RANGE COLUMNS에 대한 확장에 대한 정보는 22.2.3.1 절“RANGE COLUMNS 파티셔닝”을 참조하십시오. + LIST 파티셔닝.파티션이 개별 값 세트 중 하나와 일치하는 열을 기반으로 선택된다는 점을 제외하고 RANGE에 의한 파티션과 유사합니다. 22.2.2 절“LIST 분할”을 참조하십시오. 이 유형의 LIST COLUMNS 확장에 대한 내용은 22.2.3.2 절“LIST COL..
■ 파티셔닝 소개비 네이티브 파티셔닝이 있는 테이블을 사용하면 ER_WARN_DEPRECATED_SYNTAX경고가 발생합니다. MySQL 5.7.17에서 5.7.20까지, 서버는 시작시 비 기본 파티션을 사용하는 테이블을 식별하기 위해 자동으로 검사를 수행합니다. 발견된 파티션은 오류 로그에 메시지를 기록합니다. 이 검사를 비활성화하려면 --disable-partition-engine-check 옵션을 사용합니다. MySQL 5.7.21 이상에서는 이 검사가 수행되지 않습니다. 이 버전에서 서버가 일반 파티셔닝 핸들러를 사용하여 테이블을 확인하려면 --disable-partition-engine-check=false로 서버를 시작해야합니다. MySQL 8.0으로의 마이그레이션을 준비하려면 비 네이티브 파..
■ 사전 지식+ IN (or = ANY) 서브 쿼리의 경우 옵티마이저는 다음 선택 사항을 갖습니다.- Semijoin- Materialization(구체화)- EXISTS 전략 + NOT IN (or ALL) 서브 쿼리의 경우 옵티마이저는 다음 선택 사항을 갖습니다.- Materialization(구체화)- EXISTS 전략 파생 테이블의 경우 옵티마이저에는 다음과 같은 선택 사항이 있습니다 (참조보기에도 적용됨).+ 파생 테이블을 외부 쿼리 블록으로 병합+ 파생 테이블을 내부 임시 테이블로 구체화 다음 설명에서는 이전 최적화 전략에 대한 자세한 정보를 제공합니다. 노트서브 쿼리를 사용하여 단일 테이블을 수정하는 UPDATE 및 DELETE 문의 제한 사항은 옵티마이저가 semijoin 또는 mater..
보조 인덱스에서 범위 스캔을 사용하여 행을 읽으면 테이블이 크고 스토리지 엔진 캐시에 저장되지 않은 경우 기본 테이블에 대한 임의의 디스크 액세스가 많이 발생할 수 있습니다. 디스크 스윕 다중 범위 읽기 (MRR) 최적화를 통해 MySQL은 먼저 인덱스 만 스캔하고 관련 행에 대한 키를 수집하여 범위 스캔에 대한 임의 디스크 액세스 수를 줄입니다. 그런 다음 키가 정렬되고 기본 키 순서대로 기본 테이블에서 행이 검색됩니다. 디스크 스윕 MRR의 동기는 무작위 디스크 액세스 수를 줄이고 대신 기본 테이블 데이터의 순차적 스캔을 달성하는 것입니다. 다중 범위 읽기 최적화는 다음과 같은 이점을 제공합니다.- MRR을 사용하면 인덱스 튜플을 기반으로 임의의 순서가 아닌 순차적으로 데이터 행에 액세스할 수 있습니..