왜 MySQL 은 하위 조회 와 join 을 추천 하지 않 습 니까?

페이지 조회 하기:
1.my sql 에 대해 서 는 하위 조회 와 join 을 추천 하지 않 는 것 은 자체 join 의 효율 이 경상 이기 때 문 입 니 다.데이터 양 이 많 으 면 효율 을 보장 하기 어렵 습 니 다.색인 표 에 따라 데 이 터 를 추출 한 다음 프로그램 에서 join,merge 데 이 터 를 만 드 는 것 을 강력 히 추천 합 니 다.
2.하위 조 회 는 더욱 사용 하지 마 세 요.효율 이 너무 떨 어 집 니 다.하위 조 회 를 실행 할 때 MYSQL 은 임시 표를 만 들 고 조회 가 끝 난 후에 이 임시 표를 삭제 해 야 합 니 다.그래서 하위 조회 의 속 도 는 어느 정도 영향 을 받 을 것 입 니 다.여기 서 임시 표를 만 들 고 없 애 는 과정 이 하나 더 생 겼 습 니 다.
3.JOIN 이 라면 끼 워 넣 어서 조회 합 니 다.작은 시 계 는 큰 시 계 를 구동 하고 색인 필드 를 통 해 연 결 됩 니 다.시계 기록 이 적 으 면 OK 입 니 다.크 면 업무 논리 에서 제어 할 수 있 습 니 다.
4.데이터 베 이 스 는 밑바닥 이 고 병목 은 흔히 데이터 베이스 이다.데이터 베 이 스 는 데이터 스토어 의 도구 일 뿐 업 무 를 추가 하지 않 는 것 을 권장 합 니 다.
1.응용 층 관련 장점
캐 시 효율 을 높 입 니 다.많은 응용 프로그램 들 이 대응 하 는 결과 대상 을 편리 하 게 캐 시 할 수 있다.연 결 된 표 에 변화 가 생 겼 다 면 조회 캐 시 를 사용 할 수 없 으 며,분 리 된 표 가 거의 바 뀌 지 않 았 다 면 이 표를 기반 으로 한 조 회 는 캐 시 결 과 를 반복 적 으로 이용 할 수 있 습 니 다.
조 회 를 분해 한 후 단일 조 회 를 실행 하면 자물쇠 의 경쟁 을 줄 일 수 있다.
응용 층 에서 관련 을 하면 데이터 베 이 스 를 쉽게 분리 할 수 있 고 고성능 과 확장 이 용이 합 니 다.
조회 자체 의 효율 도 높 아 질 수 있다.아 이 디 집합 을 조회 할 때 관련 검색 대신 IN()을 사용 하면 MySQL 이 아 이 디 순 으로 조회 할 수 있 는데 이것 은 무 작위 연결 보다 효율 적일 수 있 습 니 다.
불필요 한 기록 의 조 회 를 줄 일 수 있다.응용 층 에서 관련 조 회 를 하 는 것 은 특정한 기록 응용 에 대해 한 번 만 조회 하고 데이터 베이스 에서 관련 조 회 를 하면 필요 할 수 있다 는 것 을 의미한다.
일부 데이터 에 중복 접근 해 야 합 니 다.이런 재 구성 은 네트워크 와 메모리 의 소 화 를 줄 일 수 있다.
더 나 아가 이렇게 하 는 것 은 응용 에서 해시 관 계 를 실현 하 는 것 이지 MySQL 의 내장 순환 관 계 를 사용 하 는 것 이 아니다.어떤 장면 들 은 해시 와 관련 된 효율 이 매우 높다.
2.응용 층 과 관련 된 사용 장면
단일 검색 결 과 를 편리 하 게 캐 시 할 수 있 을 때
데 이 터 를 다른 MySQL 서버 에 분포 할 수 있 을 때
관련 검색 어 대신 IN()을 사용 할 수 있 을 때
동시 다발 장면 이 많 고 DB 조회 가 빈번 하 므 로 라 이브 러 리 구분 표 가 필요 합 니 다.
3.join 을 추천 하지 않 는 이유
1.DB 가 부담 하 는 업무 스트레스 가 커서 부담 을 줄 일 수 있 으 면 줄어든다.표 가 백만 단계 에 있 으 면 join 은 성능 이 떨 어 집 니 다.
2.분포 식 라 이브 러 리 분 표.이 럴 때 는 크로스 라 이브 러 리 join 을 권장 하지 않 습 니 다.현재 my sql 의 분포 식 미들웨어,크로스 라 이브 러 리 join 의 표현 이 좋 지 않 습 니 다.
3.수정 표 의 schema,단일 표 조회 의 수정 이 비교적 쉽 습 니 다.join 이 쓴 sql 문 구 는 수정 해 야 합 니 다.쉽게 발견 되 지 않 고 원가 가 비교적 높 으 며 시스템 이 비교적 클 때 유지 하기 어렵 습 니 다.
4.join 을 사용 하지 않 는 솔 루 션
업무 층 에서 한 표 로 데 이 터 를 조회 한 후 조건 으로 다음 표 에 조회 합 니 다.하위 조회 다.하위 조회 결과 집 이 너무 많 을 까 봐 걱정 됩 니 다.my sql 은 in 의 수량 에 제한 이 없 지만 my sql 은 전체 sql 문장의 크기 를 제한 합 니 다.매개 변수 max 조정 을 통 해allowed_packet,sql 의 최대 값 을 수정 할 수 있 습 니 다.업무 상 처 리 를 잘 하고 한 번 에 조회 되 는 결과 집 을 제한 하 는 것 은 받 아들 일 수 있 습 니 다.
5.join 조회 의 장점
관련 조회 의 장점 은 페이지 를 나 눌 수 있 고 부표 의 필드 로 조회 조건 을 할 수 있 으 며 조회 할 때 부표 가 일치 하 는 필드 를 결과 집합 으로 하고 주표 로 in 을 사용 할 수 있다 는 것 이다.그러나 문제 가 생 겼 습 니 다.일치 하 는 데이터 양 이 너무 많 으 면 안 됩 니 다.돌아 오 는 페이지 기록 이 실제 와 다 를 수 있 습 니 다.해결 방법 은 전단 에 맡 기 고 한꺼번에 조회 하여 전단 에 나 누 어 표시 하면 됩 니 다.이런 해결 방안 의 전 제 는 데이터 양 이 많 지 않 기 때 문 입 니 다.sql 자체 의 길이 가 유한 하기 때 문 입 니 다.
MySQL 이 왜 하위 검색 과 join 을 추천 하지 않 는 지 에 대한 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 MySQL 하위 검색 과 join 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 부탁드립니다!