■ 파티셔닝 타입 이 섹션에서는 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..
■ 파티셔닝 소개 비 네이티브 파티셔닝이 있는 테이블을 사용하면 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을 사용하면 인덱스 튜플을 기반으로 임의의 순서가 아닌 순차적으로 데이터 행에 액세스할 수 있습..
ICP(Index Condition Pushdown)는 MySQL이 인덱스를 사용하여 테이블에서 행을 검색하는 경우를 위한 최적화입니다. ICP가 없으면 스토리지 엔진은 인덱스를 탐색하여 기본 테이블에서 행을 찾아 행의 WHERE 조건을 평가하는 MySQL 서버로 리턴합니다. ICP가 활성화 된 상태에서 인덱스의 컬럼만 사용하여 WHERE 조건의 일부를 평가할 수 있으면 MySQL 서버는 WHERE 조건의 이 부분을 스토리지 엔진으로 푸시 다운합니다. 그런 다음 스토리지 엔진은 인덱스 항목을 사용하여 푸시된 인덱스 조건을 평가하며, 이 조건을 만족하는 경우에만 테이블에서 읽은 행이 됩니다. ICP는 스토리지 엔진이 기본 테이블에 액세스해야하는 횟수와 MySQL 서버가 스토리지 엔진에 액세스해야하는 횟수를..
이 최적화는 인덱싱되지 않은 열과 상수간 직접 비교의 효율성을 향상시킵니다. 이러한 경우 조건은 평가를 위해 스토리지 엔진에 "밀어 넣어집니다(pushed down)". 이 최적화는 NDB 스토리지 엔진에서만 사용할 수 있습니다. NDB 클러스터의 경우, 이 최적화를 통해 클러스터의 데이터 노드와 쿼리를 실행한 MySQL 서버 간에 네트워크를 통해 비매칭 행을 전송할 필요가 없으며, 조건 푸시다운이 가능하지만 사용되지 않는 경우보다 5~10배 빠른 쿼리를 수행할 수 있습니다. NDB 클러스터 테이블이 다음과 같이 정의되었다고 가정합니다. CREATE TABLE t1 ( a INT, b INT, KEY(a) ) ENGINE=NDB; 조건(condition) 푸시 다운은 여기에 표시된 것과 같은 쿼리에 사용..
■ 쿼리 형태 insert into table select * from table1, table2, table3 where ... create table as select * from table1, table2, table3 where ... 위 형태의 쿼리를 사용할때는 주의 하여야 합니다. 보통 위의 쿼리는 똑같은 형태의 테이블을 생성하거나 똑같은 데이터를 특정 테이블에 밀어넣을때 많이 사용합니다. 하지만 위의 쿼리를 실행하게 되면 select를 하게되는 table1,table2,table3에는 read lock이 걸리게 됩니다. 이는 isolation level이 REPATABLE_READ일때 발생하게 됩니다. 이 REPATABLE_READ의 특징은 현재 select의 데이터 정합성과 버전을 보장하기..
■ LOCK TABLES 그리고 UNLOCK TABLES 문법 LOCK TABLES tbl_name [[AS] alias] lock_type [, tbl_name [[AS] alias] lock_type] ... lock_type: { READ [LOCAL] | [LOW_PRIORITY] WRITE } UNLOCK TABLES MySQL은 클라이언트 세션이 테이블에 액세스하기 위해 다른 세션과 협력하거나 세션에 독점 액세스가 필요한 기간 동안 다른 세션이 테이블을 수정하지 못하도록 하기 위해 명시적으로 테이블 잠금을 획득할 수 있도록 합니다. 세션은 자체 잠금만 획득하거나 해제할 수 있습니다. 한 세션은 다른 세션에 대한 잠금 또는 다른 세션이 보유한 잠금 해제를 획득할 수 없습니다. 잠금은 트랜잭션을 ..
■ 트랜잭션 격리 수준 [Isolation Level] 트랜잭션 격리는 데이터베이스 처리의 기초 중 하나입니다. 격리는 약어 ACID의 I입니다. 격리 수준은 여러 트랜잭션이 동시에 변경하고 쿼리를 수행 할 때 결과의 성능과 안정성, 일관성 및 재현성 간의 균형을 미세 조정하는 설정입니다. InnoDB는 SQL:1992 표준에 의해 기술 된 READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ 및 SERIALIZABLE의 4 가지 트랜잭션 격리 수준을 모두 제공합니다. InnoDB의 기본 격리 수준은 REPEATABLE READ입니다. 사용자는 단일 세션 또는 SET TRANSACTION문으로 모든 후속 연결에 대한 분리 레벨을 변경할 수 있습니다. 모든 연결에 대해 ..
■ InnoDB 데드록 교착 상태는 각 트랜잭션마다 다른 잠금이 있기 때문에 다른 트랜잭션을 진행할 수 없는 상황입니다. 두 트랜잭션 모두 자원이 사용 가능할 때까지 대기하므로 보유한 잠금을 서로 해제않아 발생합니다. 트랜잭션이 여러 테이블에서 행을 잠글때(UPDATE 또는 SELECT ... FOR UPDATE와 같은 SQL을 통해) 교착 상태가 발생할 수 있지만 반대 순서로 발생합니다. 교착 상태는 이러한 명령문이 인덱스 레코드 및 간격 범위를 잠그고 각 트랜잭션이 타이밍 문제로 인해 일부 잠금을 획득하지만 다른 잠금은 획득하지 않는 경우에도 발생할 수 있습니다. 교착 상태의 가능성을 줄이려면 LOCK TABLES문 대신 트랜잭션을 사용합니다. 데이터를 삽입하거나 업데이트하는 트랜잭션을 장기간 열어 ..
잠금상태에서 읽기, UPDATE 또는 DELETE는 일반적으로 SQL문 처리시 스캔되는 모든 인덱스 레코드에 대해 레코드 잠금을 설정합니다. 명령문에 행을 제외시킬 WHERE조건이 있는지 여부는 중요하지 않습니다. InnoDB는 정확한 WHERE조건을 기억하지 않지만 스캔된 인덱스 범위만 알고 있습니다. 잠금 장치는 일반적으로 레코드 바로 앞의 "GAP"에 삽입을 차단하는 Next-Key 잠금 장치입니다. 그러나 GAP 잠금을 명시적으로 비활성화하여 Next-Key 잠금을 사용하지 않을 수 있습니다. 트랜잭션 격리 수준은 설정된 잠금에 영향을 줄 수 있습니다. 검색에 보조 인덱스가 사용되고 설정될 인덱스 레코드 잠금이 배타적 일 경우 InnoDB는 해당 클러스터형 인덱스 레코드를 검색하여 잠금을 설정합니..
■ 앞축에 관련된 InnoDB INFORMATION_SCHEMA 테이블 압축에 관한 InnoDB INFORMATION_SCHEMA 테이블에는 압축이 전체적으로 얼마나 잘 작동하는지에 대한 아주 유용한 정보를 제공하는 두개의 테이블이 있습니다. + INNODB_CMP 및 INNODB_CMP_RESET은 압축 조작 수 및 압축 수행에 소요된 시간에 대한 정보를 제공합니다. + INNODB_CMPMEM 및 INNODB_CMPMEM_RESET은 메모리가 압축을 위해 할당되는 방법에 대한 정보를 제공합니다. □ INNODB_CMP와 INNODB_CMP_RESET INNODB_CMP 및 INNODB_CMP_RESET 테이블은 압축 테이블 관련 작업에 대한 상태 정보를 제공합니다. PAGE_SIZE열은 압축된 페이지..