합니다, 개발공부📝 합니다, 개발공부📝

인덱스 설계에 이어서 이번엔 DB 최적화 부분과 JPA와 함께 MySQL Replicatioin을 구현하는 방법에 대해서 배웠다. DB 최적화 대상 Connector (Client) MySQL 서버에 접근하기 위해 Application에서 설치하여 사용할 수 있는 모듈들 이를 사용하여 MySQL 서버와 통신할 수 있음 복수 건의 레코드를 한번의 호출로 집합처리 하거나 두 개 이상의 쿼리를 한 쿼리로 통합 처리 (호출수 줄이기) MySQL의 인스턴스 부분 Client로 부터 들어온 쿼리를 분석하고 최적화하여 실행계획을 만들고 필요한 경우 메모리에 cache JDBC Statement : 쿼리 문장을 분석, 컴파일, 실행단계 캐싱 PreparedStatement : 처음 한번만 세단계를 거친 후 캐시에 담아..

이번에는 쿼리 최적화에 이어 인덱스 설계를 이용하여 조회성능을 개선하는 방법에 대해서 배웠다. Table Full Scan vs Index Range Scan Table Full Scan 시퀀셜 액세스와 Multiblock I/O 방식으로 디스크를 읽어 한 블록에 속한 모든 레코드를 한번에 읽어들임 읽을 데이터가 일정량을 넘으면 유리 대량데이터 처리 Index Range Scan 랜덤 액세스와 Single Block I/O로 레코드 하나를 읽기 위해 매번 I/O가 발생 큰 테이블에서 소량 데이터를 검색할 때 (ex)OLTP) 인덱스 갱신 때문에 불필요한 오버헤드 발생 가능 MySQL에서의 Index Range Scan MySQL InnoDB의 경우 인덱스 스캔 -B트리 인덱스구조가 기본이다. 수직적 탐색..

이번엔 저번 화면 응답 개선에 이어 조회 성능을 개선하는 것을 배웠다! 먼저 쿼리 최적화에 대해서 정리하자. 쿼리 동작 방식 쿼리 캐싱 KEY : SQL문, VALUE : 쿼리의 실행결과 인 Map 데이터 변경시 모두 삭제되어 동시처리 성능저하를 일으키기 때문에 MySQL 8.0부터 사라졌다 Parsing 사용자로부터 요청된 SQL을 작게 만들어 서버가 이해할 수 있는 수준으로 분리 Preprocessor ( 전처리기 ) 해당쿼리의 문법을 확인하여 오류가 있다면 처리중단 (일괄 처리내에 있으면 일괄처리 전체 중단) 실제 존재하지 않거나 권한상 사용할 수 없는 개체의 토큰은 이 단계에서 걸러짐 Optimization 실행계획(Exception Plan)은 이 단계에서의 출력을 의미 사용자의 요청으로 들어온..