Mysql 최적화 기법 의 Limit 조회 최적화 분석

머리말
실제 업무 에서 페이지 를 나 누 는 데 있어 서 비교적 흔히 볼 수 있 는 업무 수요 이다.그러면 limit 조 회 를 사용 합 니 다.우리 가 Limit 조 회 를 사용 할 때 데이터 가 비교적 작 거나 앞의 데이터 만 조회 할 때 효율 이 높 습 니 다.그러나 데이터 양 이 많 을 때,또는 offset 수량 이 비교적 많 을 때,예 를 들 어 limit 100000,20 효율 은 종종 만 족 스 럽 지 못 하 다.일반적인 방법 은 Limit 가 order by 에 맞 추 는 것 입 니 다.order by 가 사용자 에 대한 색인 이 있 으 면 효율 이 좋 습 니 다.
이런 상황 에 대해 가장 간단 한 조 회 는 덮어 쓰기 색인 을 사용 하여 필요 한 열 을 조회 하 는 것 이다.이런 효과 가 좋아요.
아래

mysql> SELECT * FROM student LIMIT 1000000,1;
+---------+------------+------------+------------+-------+---------------------+
| id  | first_name | last_name | created_at | score | updated_at   |
+---------+------------+------------+------------+-------+---------------------+
| 1000001 | kF9DxBgnUi | yLXnPSHJpH | 2019-07-11 | 97 | 2019-07-11 14:29:59 | |
+---------+------------+------------+------------+-------+---------------------+
1 rows in set (0.31 sec)
시간 이 보 여요.

mysql> EXPLAIN SELECT score,first_name FROM student ORDER BY created_at LIMIT 1000000,20 \G
*************************** 1. row ***************************
   id: 1
 select_type: SIMPLE
  table: student
 partitions: NULL
   type: index
possible_keys: NULL
   key: time_sorce_name
  key_len: 69
   ref: NULL
   rows: 1000001
  filtered: 100.00
  Extra: Using index
1 row in set, 1 warning (0.00 sec)

mysql>
이렇게 되면 검색 의 열 이 덮어 쓰기 색인 을 사용 하면 검색 줄 수가 많이 줄 어 들 지만 이런 효과 도 만 족 스 럽 지 않 지만 다른 검색 이 있 으 면 이런 검색 도 느 려 집 니 다.
예 를 들 어 우리 에 lastname 열.
아래 와 같다

mysql> SELECT score,first_name,last_name FROM student ORDER BY created_at LIMIT 1000000,1;
+-------+------------+------------+
| score | first_name | last_name |
+-------+------------+------------+
| 86 | knKsV2g2fY | WB5qJeLZuk |
+-------+------------+------------+
1 row in set (4.81 sec)

mysql>
이 조 회 는 4 초 이상 실행 해 야 한다.분석 을 통 해 이 조 회 는 색인 을 사용 할 방법 이 없다 는 것 을 알 수 있다.

mysql> explain SELECT score,first_name,last_name FROM student ORDER BY created_at LIMIT 1000000,1\G
*************************** 1. row ***************************
   id: 1
 select_type: SIMPLE
  table: student
 partitions: NULL
   type: ALL
possible_keys: NULL
   key: NULL
  key_len: NULL
   ref: NULL
   rows: 6489221
  filtered: 100.00
  Extra: Using filesort
1 row in set, 1 warning (0.00 sec)

mysql>
그러면 우 리 는 지금 조 회 를 아래 와 같이 수정 합 니 다.

mysql> SELECT student.score,student.first_name FROM student INNER JOIN (SELECT id FROM student ORDER BY created_at LIMIT 1000000,1 ) AS temp USING(id);
+-------+------------+
| score | first_name |
+-------+------------+
| 15 | 2QWZ  |
+-------+------------+
1 row in set (0.18 sec)

mysql> EXPLAIN SELECT student.score,student.first_name,last_name FROM student INNER JOIN (SELECT id FROM student ORDER BY created_at LIMIT 1000000,1 ) AS temp USING(id);
+----+-------------+------------+------------+--------+---------------+-----------------+---------+---------+---------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys | key    | key_len | ref  | rows | filtered | Extra  |
+----+-------------+------------+------------+--------+---------------+-----------------+---------+---------+---------+----------+-------------+
| 1 | PRIMARY  | <derived2> | NULL  | ALL | NULL   | NULL   | NULL | NULL | 1000001 | 100.00 | NULL  |
| 1 | PRIMARY  | student | NULL  | eq_ref | PRIMARY  | PRIMARY   | 4  | temp.id |  1 | 100.00 | NULL  |
| 2 | DERIVED  | student | NULL  | index | NULL   | time_sorce_name | 69  | NULL | 1000001 | 100.00 | Using index |
+----+-------------+------------+------------+--------+---------------+-----------------+---------+---------+---------+----------+-------------+
3 rows in set, 1 warning (0.00 sec)
분석 결 과 를 보면 이때 1000001 개의 데이터 기록 만 조회 한 것 을 볼 수 있다.왜 이렇게 변 했 을 까?지연 연결 이 라 고 합 니 다.먼저 덮어 쓰기 색인 조 회 를 통 해 필요 한 홈 키 를 되 돌려 주 고 홈 키 관련 원 표 에 따라 필요 한 데 이 터 를 얻 으 며 스 캔 할 줄 수 를 최대한 줄 입 니 다.
어떤 특정한 상황 에서 사실은 또 다른 최적화 방안 이 있다.예 를 들 어 최신 몇 개의 삽입 기록 을 가 져 오 려 고 합 니 다.그러면 지난번 조회 때 마지막 으로 기 록 된 메 인 키 ID(lastid)。
그러면 검색 을 바 꿀 수 있 습 니 다.

SELECT score,first_name,last_name,id FROM student WHERE id>=last_id ORDER BY id ASC LIMIT 1
예 를 들 어 lastid=1000000 그러면 이 조 회 는 1000000 부터 시 작 됩 니 다.이런 장면 은 데이터 가 아무리 큰 offset 까지 성능 이 좋 을 것 이다.
총결산
이상 은 이 글 의 모든 내용 입 니 다.본 고의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 참고 학습 가 치 를 가지 기 를 바 랍 니 다.여러분 의 저희 에 대한 지지 에 감 사 드 립 니 다.

좋은 웹페이지 즐겨찾기