Technique/RDBMS
-
MySQL 쿼리 캐시Technique/RDBMS 2016. 4. 10. 19:35
쿼리 캐시( Query Cache ) 는 타 DBMS에는 없는 MySQL의 독특한 기능 중 하나로서 적절히 설정만 해두면 상당한 성능 향상 효과를 얻을 수 있다. 여러 가지 복잡한 처리 절차왜 꽤 큰 비용을 들여 실행된 결과를 쿼리 캐시에 담아 두고, 동일한 쿼리 요청이 왔을 때 간단하게 쿼리 캐시에서 찾아서 바로 결과를 내려 줄 수 있기 때문에 기대 이상의 효과를 거둘 수 있다.하지만 항상 그렇 듯이 이 쿼리 캐시에도 장단점이 있으므로 적절한 조율이 중요하다. 쿼리 캐시는 단어의 이미와는 달리 SQL 문장을 캐시하는 것이 아니라 쿼리의 결과를 메모리애 캐시해두는 기능이다. 쿼리 캐시의 구조는 간단한 키와 값의 쌍으로 관리되는 맵( map )과 같은 데이터 구조로 구현돼 있다. 여기서 키를 구성하는 요소..
-
MySQL 쿼리 실행 구조Technique/RDBMS 2016. 4. 10. 18:21
- 파서파서는 사용자 요청으로 들어온 쿼리 문장을 토큰( MySQL이 인식할 수 있는 최소 단위의 어휘나 기호) 으로 분리해 트리 형태의 구조로 만들어 내는 작업을 의미한다. 쿼리 문장의 기본 문법 오류는 이 과정에서 발견되며 사용자에게 오류 메시지를 전달하게 된다. - 전처리기파서 과정에서 만들어진 파서 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 확인한다. 각 토큰을 테이블 이름이나 칼럼 이름 또는 내장 함수와 같은 개체를 매핑해 해당 객체의 존재 여부와 객체의 접근권한 등을 확인하는 과정을 이 단계에서 수행한다. 실제 존재하지 않거나 권한상 사용할 수 없는 개체의 토큰은 이 단계에서 걸러진다. - 옵티마이저옵티마이저란 사용자의 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할..
-
InnoDB와 MyISAM 스토리지 엔진 비교Technique/RDBMS 2016. 4. 10. 17:47
MyISAM 스토리지 엔진이 인덱스를 위한 키 캐시를 가지고 있지만 데이터 자체는 운영체제의 캐시에 읜존하는 반면 InnoDB스토리지 엔진은 자ㅔ적인 버퍼 풀을 가지고 좀 더 업무 특성에 맞는 캐싱이나 버퍼링을 수행한다레코드 수준의 잠금 관리로 인해 동시성도 MyISAM을 훨씬 능가한다. 그나마 MyISAM의 전문 검색 기능이 myISAM을 선택할 이유를 만들어 주기도 하겠지만 사실 검색 기능 또한 제약이 심하다. 이미 전문 검색을 위해서는 스핑크스나 트리톤 같은 다른 서드파티 소프트웨어를 많이 사용하는 편이다. 혹시나 아직도 MyISAM이 빠를 것이라고 생각하는 사용자가 있다면 직접 테스트해볼 것을 권장한다. 읽기 방법 성능 비교 프라이머리 키( 데이터 파일 읽기 포함 ) InnoDB가 6-9% 정도 ..
-
[ 메모 ] MySQL index에 대하여Technique/RDBMS 2016. 3. 31. 11:57
인덱스에 대한 깊은 내용은 뒤에서 다루고, 우선 기본적인 것과 깊게 깨달은 것 1. 인덱스 컬럼이 날짜 형식일때 where 절에 날짜 범위를 입력하면 그 컬럼이 인덱스로 지정되어 있더라도 풀스캔 한다ex) select * from table A where create_date between A and B; -> full scan-> select * from table A where create_date = A; 2. 인덱스 컬럼이 int인경우 where 절에 in 을 이용한 조건을 사용할 경우 플스캔 한다ex) select * from table A where column_a` IN ( '10','11', '12' ); -> full scan-> select * from table A where colu..
-
[ 메모 ] MySQL SQL_CALC_FOUND_ROWS, FOUNT_ROWS() 키워드Technique/RDBMS 2016. 3. 31. 11:54
MySQL로 작업을 하던중 검색되는 모든 행의 수를 알고 싶을 경우가 있다.보통 PHP의 MySLQ 함수나 MySQLi함수 계열에선 result타입에 보면 num_rows()라는 녀석이 있어 이걸 참조하면 검색 되는 모든 결과를 알고 있다.하지만 쿼리에 LIMIT를 거는 경우엔 전체수를 알려면 쿼리를 2번 던져야 하는 번거로움(?) 이 있다.이를 조금이라도 더 쉽게 하고자 SQL_CALC_FOUND_ROWS 키워드를 사용한다.사용법은 ①SELECT SQL_CALC_FOUND_ROWS * FROM Table LIMIT 0, 10;②SELECT FOUND_ROWS() AS total;이 2개의 쿼리를 전송하는 것으로 가능하다.①의 쿼리는 10개의 행을 가져 오지만 이때 지정한 SQL_CALC_FOUND_RO..
-
[ 메모 ] is null 을 사용한 order byTechnique/RDBMS 2016. 3. 31. 11:50
is null을 사용한 order by 사용 예) SELECT * FROM table_name WHERE condition=? ORDER BY view_order IS NULL ASC, view_order asc; 라는 쿼리를 날려 보니 내가 원하는 대로 view_order가 숫자대로 지정된 놈은 그대로 정열 되고 Null인 경우엔 맨 밑으로 정렬 되었다 오예! MySQL에서 NULL 이란 값이 있긴 한데 뭔지 모르겠단 의미 이다. 주의주의
-
Primary Key, Unique Index 에 대하여Technique/RDBMS 2015. 12. 23. 23:04
Primary Key를 아무생각없이 넣거나,단순히 개발의 용이성과, 유지보수의 편의성때문에 Unique Index를 당연시 여기거나 하는가? 항목 Primary key Unique Index 목적 Constraint + Index Index 공통점 유일성 보장 유일성 보장 참조 무결성 PK/FK에 의해 지정가능 지정 불가능 테이블당 개수 1개만 가능 여러개 가능 인덱스 생성 Unique Index 생성 Unique Index 생성 역공학 적용 시 PK 인식가능 PK 인식 불가능 Null 허용 허용 안됨 허용됨 PK와 UI가 비슷한 것 같지만 세부적인 애용에 잉서서는 차이가 분명히 있다. Unique Index만을 이용하였을 때 장단점 장점 단점 - PK/FK가 존재하지 않아 DBA가 데이터베이스를 관리하..
-
엔티티타입, 통합? 분리?Technique/RDBMS 2015. 12. 23. 22:15
데이터 모델링을 하다보면 1:1관계 1:M 관계, M:M 관계를 통한 엔티티타 간에분리된 형태의 많은 엔티티타입들이 도출된다.반대로 하나의 엔티티타입 안에 비슷하지만 트랜잭션의 ㅓ리 패턴에 따라 다르게 처리되는 컬럼들이 뭉쳐서 설계되는 경우도 있다. 통합과, 분리는 결정하는 기준은 무엇인가?적절한 기준에 따라 엔티티타입의 통합과 분리를 결정하는 것은 전문적인 모델링을 전개하는 사람에게 매우 필요한 기술이다.엔티티타입의 통합과 분리도 단순하게 엔티티타입의 모습만을 보고 결정하는 것이 아니다.분석의 대상이 되는 업무 패턴을 먼저 이해하고 해당 업무에서 날아오는 트랜잭션의 패턴을 분석한 다음 엔티티타입의 통합과 분리를 결정해야 한다. ■ 무조건 통합하지 말라통합을 하다보면 데이터 모델이 단순해지고 구축하면 많..