MySQL 에서 검색 어 를 다시 쓰 는 세 가지 정책

문제 가 있 는 조 회 를 최적화 할 때 우 리 는 조회 결 과 를 얻 는 방식 을 바 꿔 야 한다.그러나 이것 은 MySQL 에서 같은 결과 집합 을 얻 는 것 을 의미 하지 않 는 다.어떤 때 는 조 회 를 같은 결 과 를 얻 지만 더 좋 은 성능 을 가 진 조회 형식 으로 바 꿀 수 있다.그러나 개발 효율 을 높 일 수 있 기 때문에 재 작성 조 회 를 통 해 다양한 결 과 를 얻 는 것 도 고려 해 야 한다.응용 프로그램 코드 를 수정 함으로써 같은 효 과 를 얻 을 수 있다.이 글 은 어떻게 조 회 를 다시 쓰 는 기 교 를 소개 할 것 이다.
복잡 한 조회 와 단계별 조회
중요 한 조회 설계 과 제 는 복잡 한 조 회 를 여러 개의 간단 한 조회 로 분해 하 는 것 이 더 좋 을 지 하 는 것 이다.전통 적 인 데이터베이스 디자인 에서 가능 한 한 적은 조회 로 대량의 업 무 를 해결 하 는 것 을 강조 한다.과거 에는 이런 방식 이 더 좋 았 을 것 이다.기 존의 인터넷 통신 비용 이 더 높 고 조회 해상도 와 최적화 기 를 고려 한 부하 때문이다.
그러나 이러한 건 의 는 MySQL 에 그다지 적용 되 지 않 습 니 다.이것 은 MySQL 처리 가 연결 을 구축 하고 연결 을 끊 는 방식 이 매우 효율 적 이 며 간단 한 조회 에 대한 응답 이 빠 르 기 때 문 입 니 다.오늘날 의 인터넷 속 도 는 이전 에 비해 큰 폭 으로 향상 되 었 다.서버 버 전에 따라 MySQL 은 일반 기기 에서 1 초 에 10 만 건 이 넘 는 간단 한 조 회 를 실행 할 수 있 으 며,천조 네트워크 에서 초당 2000 건의 조회 통신 을 완료 할 수 있다.따라서 분포 조 회 를 하 는 것 은 과거 에 말 했 던 것 처럼 나 쁘 지 않다.
초당 옮 겨 다 니 는 데이터 줄 수 에 비해 연결 응답 은 여전히 느리다.메모리 데이터 에서 이 시간 은 밀리초 급 에 이 르 렀 다.물론 가능 한 한 조회 횟수 를 사용 하 는 것 도 좋 은 선택 이다.그러나 때때로 우 리 는 복잡 한 조 회 를 몇 가지 간단 한 조회 로 나 누 어 성능 을 향상 시 킬 수 있다.이어서 우 리 는 약간의 예 시 를 보 여줄 것 이다.
프로그램 설계 에서 너무 많은 조 회 를 사용 하 는 것 은 자주 저 지 르 는 오류 이다.예 를 들 어 일부 응용 프로그램 은 10 줄 의 데 이 터 를 얻 기 위해 10 개의 단독 조 회 를 실 행 했 고 이 는 10 줄 의 데 이 터 를 조회 하 는 조 회 를 통 해 이 루어 질 수 있다.따라서 매번 조 회 를 하 는 분할 을 제창 하 는 것 이 아니 라 실제 상황 에 따 른 것 이다.
절 분 조회 문
또 다른 방식 은 분할 조회 후 재 구성 하 는 것 이다.빅 데이터 양의 조 회 를 통 해 더 작은 범위 로 나 누 어 조회 함으로써 매번 영향 을 주 는 줄 수 를 줄인다.
낡은 데 이 터 를 깨끗이 씻 는 것 이 전형 적 인 예 이다.주기 적 인 세척 데이터 작업 은 대량의 데 이 터 를 제거 하고 이런 작업 을 하면 장시간 동안 대량의 데이터 줄 을 잠 글 수 있다.이 작업 은 트 랜 잭 션 로 그 를 만 들 고 많은 자원 을 소모 하 며 끊 기지 말 아야 할 작은 데이터 의 조 회 를 막 을 수 있 습 니 다.DELETE 문 구 를 구분 한 후 중간 규모 의 조 회 를 사용 하면 성능 을 현저히 개선 할 수 있 고 조회 가 중복 되 었 을 때 중복 조회 가 발생 하 는 추가 지연 을 줄 일 수 있다.예 를 들 어 다음 삭제 문:

DELETE FROM messages WHERE created < DATE_SUB(NOW(), INTERVAL 3 MONTH);

사용 하 는 의사 코드 의 형식 은 다음 과 같 습 니 다.

rows_affected = 0
do {
  rows_affected = do_query (
  "DELETE FROM messages WHERE created < DATE_SUB(NOW(), INTERVAL 3 MONTH)
  LIMIT 10000")
  } while rows_affected > 0

한 번 에 10000 줄 을 삭제 하 는 것 은 매번 조회 의 효율 을 높이 는 데 충분 한 임무 이다.충분 한 짧 은 작업 은 서버 에 미 치 는 영향 을 줄 일 수 있다.DELETE 문구 에 휴면 시간 을 삽입 하 는 것 도 좋 은 생각 이다.이렇게 하면 시간 적 으로 부 하 를 분산 시 키 고 자 물 쇠 를 가 진 지속 시간 을 단축 시 킬 수 있다.
공동 조회 해체
많은 고성능 응용 프로그램 들 이 연합 조 회 를 해체 할 것 이다.연합 조 회 를 여러 개의 단일 표 로 나 누 어 조회 한 다음 응용 에서 결 과 를 조합 할 수 있다.예 를 들 면:

SELECT * FROM tag
	JOIN tag_post ON tag_post.tag_id=tag.id
  JOIN post ON tag_post.post_id=post.id
WHERE tag.tag='mysql';

이 공동 조 회 를 다음 과 같은 부분 으로 나 눌 수 있다.

SELECT * FROM tag WHERE tag='mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123, 456, 567, 9098, 8904);

주:여기 tagid=1234 와 post.id IN(123,456,567,9098,8904)은 모두 앞에서 조회 한 결 과 를 바탕 으로 얻 은 값 이다.왜 그 랬 어 요?첫눈 에 과 거 를 보 니 불필요 한 것 같다.조회 횟수 를 늘 렸 을 뿐이다.그러나 이런 재건 축 조 회 는 다음 과 같은 장점 을 가 져 올 수 있다.

캐 시 메커니즘 이 더욱 효과 적일 것 이다.많은 응용 프로그램 이 ORM 맵 데이터 시트 를 직접 사용 합 니 다.이 예 에서 tag 가 my sql 인 대상 이 캐 시 되 어 있 으 면 첫 번 째 조 회 는 건 너 뜁 니 다.posts 의 id 가 123,567 또는 9908 이면 IN 목록 에서 이 몇 개 를 삭제 할 수 있 습 니 다.이런 정책 을 통 해 캐 시 를 조회 하면 상응하는 이익 을 얻 을 수 있다.만약 그 중의 한 표 만 자주 변화 한다 면,연합 조 회 를 해체 하면 캐 시가 효력 을 잃 는 횟수 를 줄 일 수 있다.

이 조 회 를 단독으로 실행 하면 잠 금 표 의 기 회 를 줄 일 수 있다.

은 이런 방식 을 통 해 데이터 베 이 스 를 쉽게 확장 하고 데이터 시트 를 다른 기계 에 올 려 놓는다.

조회 자체 최적화 할 수 있 습 니 다.이 예 에서 공동 검색 대신 IN 검색 을 사용 하면 MySQL 이 줄 ID 를 정렬 하고 데이터 줄 을 가 져 오 는 것 이 더 좋 을 수 있 습 니 다.

은 불필요 한 방문 을 줄 일 수 있다.이 방식 을 사용 하 는 것 은 데이터 줄 을 한 번 만 가 져 오 는 것 을 의미 하 며,공동 조회 에서 같은 데 이 터 를 반복 적 으로 가 져 올 수 있다.이런 이유 로 이런 해체 방식 도 전체 네트워크 부하 와 메모리 점용 을 줄 일 수 있다.

확장 을 통 해 MySQL 공동 조회 의 내장 순환 을 대체 할 수 있 으 며,해시 공동 조회 도 더욱 효과 적일 수 있 습 니 다.

최종 적 으로 공동 조 회 를 통 해 캐 시 재 활용 성 을 높 일 수 있 고 다 중 서버 분포 식 데이터 방안 이 더욱 간단 하 며 큰 데이터 시트 에서 공동 조회 나 같은 표 의 여러 번 중복 조 회 를 대신 할 수 있 음 을 알 수 있다.
이상 은 MySQL 에서 검색 어 를 다시 쓰 는 세 가지 전략의 상세 한 내용 입 니 다.MySQL 에서 검색 어 를 다시 쓰 는 것 에 관 한 자 료 는 저희 의 다른 관련 글 을 주목 하 십시오!