JIN_CODER

프라이머리 키에 의함 클러스터링 InnoDB의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링 되어 저장됨 키 값의 순서대로 디스크에 저장됨 모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용됨 레인지 스캔은 빨리 처리됨 쿼리의 실행 계획에서 프라이머리 키는 기본적으로 다른 보조 인덱스에 비해 비중이 높게 설정 InnoDB 스토리지 엔진과는 달리 myISAM 스토리지 엔진에서는 클러스터링 키를 지원하지 않음 외래키 지원 외래키는 데이터베이스 서버 운영의 불편함 때문에 서비스용 데이터베이스에서는 생서하지 않는 경우도 있음 개발 환경에서는 좋은 가드 역할을 하기도 함 외래키는 부모 자식 테이블의 인덱스 생성이 필요하고, 데이터 유무를 체크 하기 때문에 잠금 및 ..

MySQL 엔진 아키텍처 머리 역할 : MySQL 엔진 손발 역할 : 스토리지 엔진 MySQL은 일반 상용 RDBMS와 같이 대부분의 프로그래밍 언어로부터 접근 방법을 모두 지원 모든 언어로 MySQL서버에서 쿼리를 사용 할 수 있게 지원 MySQL 엔진 클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션핸들러, SQL 파서 및 전처리기, 쿼리의 최적화된 실행을 위한 옵티마이저가 중심을 이룸 스토리지 엔진 MySQL 엔진은 요청된 SQL 문장을 분석하거나 최적화 하는 등 DBMS의 두뇌에 해당하는 처리를 수행 실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분은 스토리지 엔진 담당 MySQL은 하나지만, 스토리지 엔진은 여러개를 동시에 사용 가능 각 스토리지 엔진은..

GROUP BY 처리 GROUP BY, ORDER BY 은 스트리밍 처리가 불가능함 GROUP BY에 사용된 조건은 인덱스를 사용할 수 없기 때문에 HAVING 절을 튜닝 하려고 인덱스를 생성하거나 다른 방법을 써도 인덱스를 사용할 수 없음 인덱스 스캔 : 인덱스를 차례로 읽는 방법 루스 인덱스 스캔 : 인덱스를 건너뛰면서 읽는 방법 인덱스를 사용하지 못하는 쿼리에서 GROUP BY는 임시테이블 사용 인덱스 스캔을 이용한 GROUP BY(타이트 인덱스 스캔) GROUP BY칼럼으로 인덱스가 있다면 인덱스를 차례로 읽으면서 그루핑을 수행하고 그 결과를 조인함 GROUP BY가 인덱스를 통해 처리되는 쿼리는 이미 정렬된 인덱스를 읽는 것이므로 쿼리 실행 시점에 추가적인 정렬 작업이나 내부 임시 테이블은 필요..

쿼리의 실행 절차 DBMS에서 쿼리의 실행 계획을 수립하는 것은 옵티마이저 1단계 : SQL 파싱, MySQL서버의 SQL 파서 라는 모듈로 처리, SQL 문장이 문법적으로 잘못됐다면 여기서 걸러짐 SQL 파스 트리가 만들어짐 2단계 : 최적화 및 실행 계획 수립 단계 불필요한 조건 제거 및 복잡한 연산의 단순화 여러 테이블의 조인이 있는 경우 어떤 순서로 테이블을 읽을지 결정 각 테이블에 사용된 조건과 인덱스 통계정보를 이용해 사용할 인덱스를 결정 가져온 레코드들을 임시테이블에 넣고 다시 한번 가공해야 하는지 결정 3단계 : 수립된 실행 계획대로 스토리지 엔진에 에코드를 읽어오도록 요청하고, MySQL엔진에서는 스토리지 엔진으로 부터 받은 레코드를 조인하거나 정렬하는 작업 수행 옵티마이저 종류 옵티마이..

트랜잭션 여러개의 변경 작업을 수행하는 쿼리가 조합됐을 때 이상이 있을경우 원래 상태로 돌아가게 해주는 기능 논이적인 작업 셋 자체가 100% 적용되거나(COMMIT을 실행했을 때) 아무것도 적용되지 않아야(ROLLBACK) 함을 보장해줌 INNODB는 쿼리 중 일부라도 오류가 발생하면 전체를 원 상태로 만든다는 트랜잭션의 원칙대로 INSERT문을 실행하기 전 상태로 그대로 복구함 MyISAM 테이블에서 발생하는 이러한 현상을 부분 업데이트라고 표현 - 부분 업데이트 현상은 테이블 데이터의 정합성을 맞추는데 상당히 어려운 문제를 만들어냄 트랜잭션은 어플리케이션 개발에서 고민해야할 문제를 줄여주는 아주 필수적인 DBMS의 기능 주의사항 트랜잭션 또한 DBMS의 커넥션과 동일하게 꼭 필요한 최소의 코드에만 ..

시진엽 공간 인덱스 R-Tree 인덱스 알고리즘을 잉요해 2차원의 데이터를 인덱싱하고 검색하는 목적의 인덱스 R-Tree는 인덱스를 구성하는 칼럼의 값이 2차원의 공간 개념 값 구조 및 특성 GEOMETRY 타입은 나머지 3개 타입의 슈퍼 타입으로 POINT와 LINE, POLYGON 객체를 모두 저장 가능함 MBR : 해당 도형을 감싸는 최소 크기의 사각형의 의미 이 사각형들의 포함 관계를 B-Tree형태로 구현한 인덱스가 R-Tree 인덱스 최하위 레벨의 MBR은 각 도형 데이터의 MBR을 의미 최상위 레벨의 MBR은 중간 크기의 MBR 최상위 MBR은 R-Tree의 루트 노드에 저장된 정보, 차상위 그룹 MBR은 R-Tree의 브랜치 노드, 마지막으로 각 도형의 객체는 리프 노드에 저장 R-Tree..

디스크 읽기 방식 데이터베이스의 성능 튜닝은 디스크 I/O를 줄이느냐가 관건 하드디스크 드라이브 HDD / 솔리드 스테이트 드라이브 SSD SSD 플래시메모리 사용 -> 데이터를 빨리 읽고 쓸수 있음 전원이 공급되지 않아도 데이터가 삭제되지 않음 HDD보다 랜덤 I/O 작업이 빠름 DBMS용 스토리지에 최적화됨 랜덤 I/O 순차 I/O 순차 I/O는 3개의 페이지(3*16KB)를 디스크에 기록하기 위해 1번의 시스템 콜을 요청 랜덤 I/O는 3개의 페이지를 디스크에 기록하기 위해 3번 시스템 콜을 요청 순차 I/O는 랜덤 I/O 보다 3배 더 빠름 디스크의 성능은 시스템 콜을 줄이고 한번에 기록하느냐에 따라 결정 됨 램덤 I/O는 여러번 시스템 콜을 요청 하기 때문에 작업 부하가 더 큼 사실 순차 I/O..

칼럼변경 테이블 구조 변경 작업은 대부분 칼럼을 추가하더나 칼럼 타입을 변경하는 작업 ALTER TABLE 명령을 이용 칼럼추가 INPLACE 알고리즘을 사용한 온라인 DDL 처리, 마지막 칼럼 추가는 INSTANT 알고리즘으로 바로 추가 가능 테이블이 큰 경우 칼럼을 마지막에 추가하는거시 좋음 칼럼 삭제 칼럼을 삭제하는 과정은 항상 테이블 리빌드를 필요로 하기 때문에 INSTANT 알고리즘을 사용할 수 없음 항상 INPLACE 알고리즘을 이용해 칼럼 삭제 가능 칼럼 이름 및 칼럼 타입 변경 칼럼값의 저장용 공간은 칼럼의 값의 바이트 수가 255 이하인 경우 1바이트만 사용하고, 256 이상 사용시 2바이트를 사용함 칼럼 최대값 변경시 1바이트 이하테이블 리빌드가 필요없지만, 1바이트에서 2바이트로 변경..

스키마조작(DDL) DDL(Data Definition Language) = DBMS 서버의 모든 오브젝트를 생성하거나 변경하는 쿼리 ex) 스토어드 프로시저나 함수, DB, 테이블 등을 생성하거나 변경하는 대부분의 명령 스키마를 변경하는 작업중에는 상당히 로랜시간이 걸리고 MySQL 서버에 많은 부하가 발생하기 때문에 주의 해야함 온라인 DDL MySQL 5.5 이전 버전은 테이블의 구조가 변경되는 동안 커넥션 연결이 어려웠지만, 온라인 DDL 기능으로 스키마 변경을 하면서 커넥션 연결이 가능해짐 ALGORITHM, LOCK 옵션을 통해 어떤 모드로 스키마를 변경할 지 선택 가능 스키마 변경 알고리즘의 우선순위가 낮을수록 MySQL 서버는 스키마 변경을 위해서 더큰 잠금과 많은 작업을 필요로 하고, 부..

INSERT INSERT 문장이 동시에 실행되는 경우 INSERT 문장 자체보다는 테이블의 구조가 서능에 더큰 영향을 미침 INSERT와 SELECT의 성능을 동시에 빠르게 만들 수 있는 테이블 구조는 없음(타협해야함) 고급옵션 INSERT IGNORE INSERT ON DUPLICATE KEY UPDATE 유니크 인덱스나 프라이머리 키에 대해 중복 레코드를 어떻게 처리할지를 결정함 INSERT IGNORE 유니크 인데스나 프라이머리 키가 중복으로 존재하는 경우, 레코드의 칼럼과 테이블의 칼럼이 서로 호환이 되지 않는 경우 모두 무시하고 다음 레코드를 처리 할 수 있게 해줌 여러 레코드를 하나의 INSERT 문장으로 처리하는 경우 유용함 salaries 테이블의 프라이머리 키 : emp_no, from_..