rows 칼럼

옵티마이저의 처리 방식

• MySQL 옵티마이저는 각 조건에 대해 가능한 처리 방식을 나열하고, 각 처리 방식의 비용을 비교해 최종적으로 하나의 실행 계획을 수립한다.
• 이때, 각 처리 방식이 얼마나 많은 레코드를 읽고 비교해야 하는지 예측해서 비용을 산정한다.
  • 대상 테이블에 얼마나 많은 레코드가 포함되어 있는지
  • 각 인덱스 값의 분포도가 어떤지 등

rows 칼럼

• 실행 계획의 효율성 판단을 위해 예측했던 레코드 건수를 보여준다.
  • 각 스토리지 엔진 별로 가지고 있는 통계 정보를 참조해 MySQL 옵티마이저가 산출해 낸 예상값이다.
  • 정확하지는 않다.
• ref 칼럼의 값은 반환하는 레코드의 예측치가 아니라 쿼리를 처리하기 위해 얼마나 많은 레코드를 읽고 체크해야 하는지를 의미한다.
  • 실행 계획의 rows 칼럼에 출력되는 값 ≠ 실제 쿼리 결과 반환된 레코드 건수

예제

• 다음은 풀 테이블 스캔(type 칼럼의 값이 ALL)을 사용하는 쿼리이다.

  EXPLAIN
  SELECT * FROM detp_emp WHERE from_date >= '1985-01-01';

  • ref 칼럼의 값이 33만 건이 나왔고, 테이블의 전체 레코드 수도 33만 건이라고 하자.
  • MySQL 옵티마이저가 이 쿼리를 처리하기 위해 약 33만 건의 레코드를 읽어야 할 것이라고 예측했음을 알 수 있다.
  • 즉, 테이블의 모든 레코드를 비교해봐야 한다고 판단했기 때문에 MySQL 옵티마이저는 풀 테이블 스캔을 선택한 것이다.
• 다음은 같은 쿼리에서 범위를 더 줄여본 쿼리이다.

  EXPLAIN
  SELECT * FROM detp_emp WHERE from_date >= '2002-07-01';

  • ref 칼럼의 값이 292가 나왔다고 하자.
  • MySQL 옵티마이저가 from_date 칼럼의 값이 ‘2002-07-01’보다 크거나 같은 레코드가 292 건만 존재할 것으로 예측한 것이다. → 전체 테이블 건수와 비교하여 8.8% 정도
  • 따라서 최종적으로 옵티마이저는 인덱스 레인지 스캔으로 처리한 것이다.

참고

• MySQL 옵티마이저가 예측하는 수치는 정확한 값을 산출하기 위한 기능이 아니므로 틀릴 가능성이 높다.
• 하지만, 대략의 수치에는 어느 정도 근접해야 옵티마이저가 제대로된 실행 계획을 수립할 수 있다.
• 가끔 인덱스되지 않은 칼럼이나 칼럼의 값이 균등하게 분포되지 않은 경우에도 제대로 된 예측을 못할 수도 있다.
  • 이련 경우를 위해 MySQL 8.0부터 히스토그램이 도입됐다.

Reference

참고 서적

📔 Real MySQL 8.0