현재 웹 API 읽기 전용 인터페이스가 수정 중이며 수정 과정에서 수정 후 응답 시간이 이전과 크게 다르지 않은 것으로 확인되었으며 테스트 결과 페이징에서 그 이유를 발견 한 것으로 나타났습니다. 다음과 같이 솔루션 최적화에 최적화되어 있습니다.
테스트 내용
실행 시간 비교는 가장 많은 플랫폼 펀드 레코드를 가진 사용자를 사용합니다. user_id 36062
테스트 횟수가 5 회가되지 않았습니다. 인덱스 캐시에서 각 테스트 전에 제한의 시작 값이 변경되는 것을 방지하기 위해 쿼리 수는 변경되지 않았습니다.
평균 5 개 결과 최적화 전 평균 쿼리 시간은 0.287 초입니다.
최적화 후 sql1 평균 쿼리 시간 0.012 초
최적화 후 sql2 의 평균 쿼리 시간은 0.016 초 입니다 .
결과는 최적화 후 sql1 및 sql2의 쿼리 효율성이 최적화 전보다 훨씬 높음을 보여줍니다.
먼저 조건을 충족하는 모든 인덱스를 찾은 다음 인덱스를 통해 필요한 데이터를 검색하면 효율성이 크게 향상됩니다.
첨부 : sql
원래 SQL
SELECT * FROM account_log WHERE user_id = 36062ORDER BY id DESC LIMIT 3300, 10;
최적화 된 SQL 1
SELECT * FROM account_log a JOIN (SELECTid FROM rd_account_log WHERE user_id = 36062 ORDER BY id DESC LIMIT 3300, 10) bON b.id = a.id;
최적화에는 SQL 2가 있습니다.
SELECT * FROM account_log WHERE user_id = 36062 AND id <= (SELECT id FROM rd_account_log
WHERE user_id = 36062 ORDER BY id DESC LIMIT33416,1) LIMIT 10
요약하자면
1. 시작 레코드가 증가함에 따라 시간도 증가합니다. 이는 페이징 명령문 한계가 시작 페이지 번호와 많은 관련이 있음을 보여줍니다.
1) limit 문의 쿼리 시간 은 시작 레코드의 위치에 비례합니다
.2) mysql의 limit 문은 매우 편리하지만 레코드가 많은 테이블에 직접 사용하기에는 적합하지 않습니다.
2. 테이블의 커버링 인덱스를 사용하여 페이징 질의 속도를 높입니다.
인덱스 질의를 사용하는 문에 인덱스 열 (커버링 인덱스) 만 포함되면이 경우 질의가 매우 빠르다는 것을 모두 알고 있습니다.
인덱스 검색에 최적화 된 알고리즘이 있고 데이터가 쿼리 인덱스에 있기 때문에 관련 데이터 주소를 찾을 필요가 없어 많은 시간을 절약 할 수 있습니다. 또한 Mysql에는 관련 인덱스 캐시가 있으며 동시성이 높을 때 캐시를 사용하는 것이 좋습니다.