천만 개 기록 페이지 조회 최적화
페이지 별 조 회 는 가장 자주 사용 되 는 장면 중 하나 이지 만, 일반적으로 가장 문제 가 생기 기 쉬 운 곳 이기 도 하 다.예 를 들 어 아래 의 간단 한 문구 에 대해 일반적으로 DBA 가 생각 하 는 방법 은 type, name, create 이다.time 필드 에 조합 색인 을 추가 합 니 다.이러한 조건 의 정렬 은 색인 에 효과적으로 이용 되 고 성능 이 신속하게 향상 된다.
SELECT *
FROM tstb_log
WHERE type = 'SQLStats'
AND name = 'SlowLog'
ORDER BY create_time
LIMIT 1000, 10;
최적화 방법
좋아, 아마 90% 이상 의 DBA 가 이 문 제 를 해결 하 는 것 은 여기까지 일 거 야.그러나 LIMIT 자구 가 'LIMIT 1000000, 10' 으로 바 뀌 었 을 때 프로그래머 는 내 가 10 개의 기록 만 가 지 는 것 이 왜 느 리 냐 고 불평 했다.
데이터 베 이 스 를 알 고 싶다 면 1000000 조 기록 이 어디에서 시작 되 는 지, 색인 이 있 더 라 도 처음부터 계산 해 야 한다.이런 성능 문제 가 발생 하면 대부분 프로그래머 가 게 으 름 을 피 우 는 경우 가 많다.
전단 데이터 조회 페이지 나 빅 데이터 분할 내 보 내기 등 장면 에서 이전 페이지 의 최대 치 를 매개 변수 로 조회 조건 으로 할 수 있 습 니 다.SQL 재 설 계 는 다음 과 같 습 니 다.
SELECT *
FROM tstb_log
WHERE type = 'SQLStats'
AND name = 'SlowLog'
AND create_time > '2017-03-16 14:00:00'
ORDER BY create_time limit 10;
새로운 디자인 에서 조회 시간 은 기본적으로 고정 되 어 데이터 양 이 증가 함 에 따라 변화 하지 않 는 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
자바 읽 기 쓰기 바 이 너 리 파일 작업텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.