ballde

InnoDB에서 Deadlock 만들기 InnoDB는 다른 DBMS와는 다르게 레코그 간의 간격을 잠그는 gap lock 이나 next key lock이 있다.순수한 레코드 레벨의 잠금만 사용하는 DBMS보다는 잠금의 범위가 넓은 편이라 데드락이 더 자주 발생하는 편이다. 패턴 1. 상호 거래 관련 A 사용자가 B사용자에게 10 포인트 전달, 그와 동시에 B 사용자도 A사용자에게 10 포인트 전달 하는 시나리오 일반적으로 차감 → 증가 순으로 개발 테이블의 프라이머리키인 user_id 값을 기준으로 처리 1번 트랜잭션: a - update 진행 2번 트랜잭션: a - update 진행 1번 트랜잭션: b - update 진행 2번 트랜잭션: b - update 진행 패턴 2. 유니크 인덱스 관련 트랜잭션..

용어 정리 배타적 잠금 - 내가 쓰기를 하는 동안 남들이 쓰지 못하게 하는 것이다. 공유 잠금 - 내가 읽는 동안 남들이 내가 읽고 있는 데이터를 변경하거나 삭제하지 못하게 하는 것이다. 트랜잭션이란 논리적인 작업셋의 완전성을 보장하기 위한 기능이고, 잠금이란 동시성을 제어하기 위한 기능 InnoDB의 기본 잠금 방식 InnoDB에서는 각 쿼리의 패턴별로 사용하는 잠금이 다르다. https://balldev.tistory.com/58 트랜잭션 격리 수준 이전글에 연장입니다.~ https://balldev.tistory.com/57 트랜잭션과 잠금 트랜잭션이란? 트랜잭션은 작업의 완전성을 보장해 주는 것이다. 즉, 논리적인 작업 셋을 모두 완벽하게 처리하거나 또는 처리하 balldev.tistory.com..

스토어드 프로그램은 스토어드 루틴이라고도 하는데, 스토어드 프로시저와 스토어드 함수 그리고 트리거와 이벤트 등을 모두 아우르는 명칭 장점 데이터베이스 보안 향상 기능의 추상화 네트워크 소요 시간 절감 절차적 기능 구현 개발 업무의 구분 단점 낮은 처리 성능 애플리케이션 코드의 조각화 애플리케이션의 설치나 배포 작업이 갈수록 복잡해지고 있다. 그런데 각 기능을 담당하는 프로그램 코드가 자바와 MySQL 스토어드 프로그램으로 분산된다면 애플리케이션의 설치나 배포가 더 복잡해지고 유지보수 또한 어려워진다. 스토어드 프로시저 자주 사용되고 복잡한 쿼리를 모듈화 시켜서 저장해놓고 필요할 때마다 손쉽게 사용이 가능 트리거 직접 트리거를 실행시킬 수 없고 어떠한 이벤트가 발생 시 트리거가 실행됨 이벤트 스케줄러 My..

파티션을 사용하는 이유 한 테이블이 너무 커서 인덱스의 크기가 물리적인 메모리보다 훨씬 크거나, 데이터 특성상 주기적인 삭제 작업이 필요한 경우 등이 파티션이 필요한 대표적인 예이다. 단일 INSERT와 단일 또는 범위 SELECT의 빠른 처리 update, delete 처리를 위해 대상 레코드를 검색하려면 인덱스는 필수적 인덱스의 워킹 셋이 실질적인 물리 메모리보다 크다면 쿼리 처리가 느려짐 파티셔닝을 안하면 인덱스가 커지고 물리적인 메모리 공간도 많이 필요해짐 → 효율적 관리를 위해 필요 데이터의 물리적인 저장소를 분리 파티션을 통해 파일의 크기를 조절하거나 각 파티션별 파일들이 저장될 위치나 디스크를 구분해서 지정해서 해결 가능 하지만 mysql에서는 인덱스를 순차적으로 생성하는 방법은 아직 허용되..

전문검색 - MySQL 의 Full Text Search(이하 FTS) LIKE같은 패턴 검색은 인덱스를 사용하지 못함 또한 LIKE를 여러 필드 (예를 들어, title과 keyword 등)에 동시에 적용하면서 여러 단어를 검색어로 전달하면 쿼리가 복잡해지기도 한다. 정규표현식도 마찬가지로 인덱스를 거치지 않고 풀 스캔(Full Scan)이 일어나기 때문에 느리다. 이런 전문 검색은 일부만 검색하는 경우에도 전용 인덱스를 사용하기 때문에 빠른 검색이 가능 FULLTEXT 검색 방식 **자연어 검색(natural search)**검색 문자열을 단어 단위로 분리한 후, 해당 단어 중 하나라도 포함되는 행을 찾는다. **불린 모드 검색(boolean mode search)**검색 문자열을 단어 단위로 분리한..

GROUP BY 사용 시 주의사항 쿼리에 GROUP BY가 사용되면 그룹 키(GROUP BY 절에 명시된 칼럼)가 아닌 칼럼은 일반적으로 집합 함수를 감싸서 사용해야 한다. SELECT first_name FROM employees GROUP BY gender; 가져온 first_name 이 제일 큰 값인지, 제일 작은 값인지 아니면 중간의 값을 가져온 것인지 알 수 없다. 그렇기 때문에 가능하다면 GROUP BY 절에 명시되지 않은 칼럼은 반드시 집합 함수로 감싸서 사용하길 권장 GROUP BY .. ORDER BY NULL MySQL의 GROUP BY은 그룹핑과 정렬 작업을 동시에 수행한다. 실제 정렬 작업이 필요하지 않을 때는 정렬은 하지 않도록 쿼리를 작성할 수 있다. ⇒ order by null..

where 절의 비교 조건 사용 시 주의사항 NULL 비교 null도 하나의 값으로 인정해서 관리 null 비교는 is null 문자열이나 숫자 비교 그 타입에 맞춰 상수를 사용할 것을 권장 DATE나 DATETIME 과 문자열 비교 DATE나 DATETIME 타입의 값과 문자열을 비교할 때는 문자열 값을 자동으로 DATETIME 타입의 값으로 변환해서 비교를 수행 DATE와 DATETIME의 비교 DATETIME 타입의 값을 DATE 타입으로 만들지 않고 그냥 비교하면 MySQL 서버가 DATE 타입의 값을 DATETIME 으로 변환해서 같은 타입을 만든 다음 비교를 수행한다. 예를 들면 DATE 타입의 값 "2017-01-26" 과 DATETIME 타입의 값 "2017-01-26 00:00:00"을 ..

인덱스를 사용하기 위한 기본 원칙 인덱스 컬럼 가공 X 예시) salary * 10 인덱스 컬럼의 데이터 타입과 where 절의 데이터 타입이 같아야함 select * from tb_test where age=2 ( age(varchar(10), index ix_age(age) ) ⇒ 이런 경우 데이터 타입이 달라서 인덱스 풀스캔 하게됨 where 절의 index 사용 범위 제한 조건 동등 비교, in으로 구성된 조건이 인덱스를 구성하는 컬럼과 얼마나 좌측부터 일치하는가에 따라 다름 SELECT * FROM employees WHERE first_name='Kebin' OR last_name='Poly'; 위 쿼리에서 first_name='Kebin' 조건은 인덱스를 이용할 수 있지만 last_name=..

👀 드라이빙 테이블 (DRIVING TABLE)이란? JOIN시 먼저 액세스 돼서 ACCESS PATH를 주도하는테이블 👀 드리븐 테이블(DRIVEN TABLE, INNER TABLE) 나중에 액세스 되는 테이블을 드리븐 테이블(DRIVEN TABLE, INNER TABLE) 조인시 영향 인덱스(INDEX)의 존재 및 우선순위 혹은 FROM절에서의 TABLE 지정 순서에 영향을 받음 많은 양의 데이터를 다룰 때, 드라이빙 테이블은 매우 중요하다. 예시 10000건의 데이터 A 5000건의 데이터 B 10000건을 먼저 드라이빙하게 된다면 -> 10000번 돌면서 B테이블 탐색 5000건을 먼저 드라이빙하게 된다면 -> 5000번 돌면서 탐색 결정 규칙 규칙기반 옵티마이저(Rule-Based Optimiz..

이전글에서 이어진 글입니다 https://balldev.tistory.com/59 5장. 인덱스 디스크 읽기 방식 데이터베이스의 성능 튜닝은 어떻게 디스크 I/O를 줄이느냐가 관건인 것들이 상당함 저장 매체 DAS 컴퓨터의 본체와 달리 디스크만 있음 모두 SATA SAS와 같은 케이블로 연결되어 balldev.tistory.com 해시 인덱스 해시 인덱스는 동등 비교 검색에는 최적화 but 범위를 검색한다거나 정렬된 결과를 가져오는 목적으로는 사용할 수 없다. DBMS에서 메모리 기반의 테이블에 주로 구현 → 대용량 테이블용으로는 사용 X 구조 및 특성 실제 키 값과는 상관 없이 인덱스 크기가 작고 검색이 빠름 검색하고자 하는 값을 주면 해시함수를 거쳐서 키 값이 포함된 버켓을 알 수 있음. 그리고 하나..