mysql 옵티마이저는 다음과 같은 조건이 일치할때 주로 풀 테이블 스캔
- 테이블의 레코드 건수가 너무 작아서 인덱스를 통해 읽는 것보다 풀 테이블 스캔을 하는 편이 더 빠른경우
- WHERE 절이나 ON 절에 인덱스를 이용할 수 있는 적절한 조건이 없는 경우
- 인덱스 레인지 스캔을 사용할 수 있는 쿼리라고 하더라도 옵티마이저가 판단한 조건 일치 레코드 건수가 너무 많은 경우
- 강제 풀 테이블 스캔을 해야하는 경우
스트리밍 처리
mysql 스트리밍 처리
서버 쪽에서 처리할 데이터가 얼마인지에 관계없이 조건에 일치하는 레코드가 검색될 때마다 바로바로 클라이언트로 전송해주는 방식을 의미한다. 이 방식으로 쿼리를 처리할 경우 클라이언트는 쿼리를 요청하고 곧바로 원했던 첫 번째 레코드를 전달 받는다.
특징
- 쿼리 결과를 한 번에 모두 생성하지 않는 방식이다.
- 대신 서버는 결과를 한 행씩 또는 작은 묶음 단위로 클라이언트에게 전송한다.
- 스트리밍 처리는 전체 결과 집합을 메모리에 저장할 필요가 없어 메모리 사용량을 줄일 수 있다.
- 결과를 점진적으로 받기 때문에, 첫 번째 결과를 빠르게 얻을 수 있고, 전체 데이터를 기다리지 않아도 된다.
- 대용량 데이터 처리나 실시간 처리가 필요한 어플리케이션에 적합하다.
mysql 버퍼링 처리
Order by나 Group by와 같은 처리는 쿼리의 결과가 스트리밍되는 것을 불가능하게 한다. 우선 where 조건에 일치하는 모든 레코드를 가져온 후, 정렬하거나 그루핑해서 차례대로 보내야 하기 때문이다.
특징
- 서버가 쿼리의 전체 결과를 먼저 생성하고 이를 메모리에 저장한 후 클라이언트에게 전송하는 방식이다.
- 결과 집합이 클라이언트로 전송되기 전에 서버 메모리에 저장되므로, 대용량 결과 집합을 처리할 때는 메모리 사용량이 증가할 수 있다.
- 작은 결과 집합을 빠르게 전체적으로 받을 수 있으므로, 데이터 크기가 작은 어플리케이션에 유리하다.
- 일반적인 웹 어플리케이션과 같이 결과 집합이 크지 않은 경우에 적합하다.
JDBC는 MySQL 서버는 레코드를 읽자마자 클라이언트로 그 결과를 전달할 것이다. 하지만 JDBC는 MySQL 서버로부터 받는 레코드를 일단 내부 버퍼에 모두 담아둔다. 그리고 마지막 레코드가 전달될 때까지 기다렸다가 모든 결과를 전달받으면 그때서야 비로소 클라이언트의 애플리케이션에 반환한다. 즉, MySQL 서버는 스트리밍 방식으로 처리해서 반환하지만 클라이언트의JDBC 라이브러리가 버퍼링하는 것이다.
Reference.
Real MySQL 8.0 (1권) | 백은빈 - 교보문고
Real MySQL 8.0 (1권) | MySQL 서버를 활용하는 프로젝트에 꼭 필요한 경험과 지식을 담았습니다!《Real MySQL 8.0》은 《Real MySQL》을 정제해서 꼭 필요한 내용으로 압축하고, MySQL 8.0의 GTID와 InnoDB 클러스
product.kyobobook.co.kr