코드 사양에서 SQL 문에 조인을 너무 많이 포함하지 않도록 요구하는 이유는 무엇입니까?

하위 질문 보내기

인터뷰어: Linux를 사용해 본 적이 있나요?

나: 예

인터뷰어:메모리 사용량을 확인하려면 어떤 명령어를 사용해야 하나요

나:free 또는 top

인터뷰어:free 명령어를 사용하면 어떤 정보를 볼 수 있는지 알려주실 수 있나요

나:글쎄요, 아래 그림처럼 메모리와 캐시 사용량을 볼 수 있어요

• 총계 memory

• used 사용된 메모리

• free free memory

• 버프/캐시 사용된 캐시

• 사용 가능한 메모리

면접관: 그럼 사용한 캐시(버프/캐시)를 지우는 방법을 아시나요

나: ... 모르겠어요

면접관: sync; echo 3 > /proc/sys/vm/drop_caches 그러면 버프/캐시를 지울 수 있어요. 이 명령을 온라인으로 실행할 수 있는지 알려주실 수 있나요?

(하위 주제 보내기, 매우 기쁩니다) 캐시를 지우면 사용 가능한 메모리 공간이 더 많아집니다. PC의 xx Guardian의 작은 로켓처럼 많은 메모리가 출시될 것입니다. 원클릭

인터뷰어:

em…., 돌아가서 알림을 기다립니다

SQL Join에 대해 다시 이야기합시다

인터뷰어:

주제를 바꿔서 Join에 대한 이해에 대해 이야기해 보세요

나:

좋아요 (한 번 더 틀리면 종료) 기회를 잡으세요)

Review

Join in SQL은 특정 조건에 따라 지정된 테이블을 결합하여 클라이언트에 데이터를 반환할 수 있습니다

참여하는 방법이 있습니다

내부 조인 내부 조인

왼쪽 조인 왼쪽 조인

오른쪽 조인 오른쪽 조인

완전 가입

이미지 출처: https://www.cnblogs.com/reaptomorrow-flydream/p/8145610.html

인터뷰어: 프로젝트 개발 중에 조인 문을 사용해야 하는 경우 어떻게 성능을 최적화하고 개선합니까?

나: 데이터 크기가 작은 상황과 데이터 크기가 큰 상황 두 가지가 있습니다.

인터뷰어: 그럼?

나:

1. 데이터 크기가 작으면 메모리에 다 넣으면 됩니다

2 데이터 크기가 크다면

• . 인덱스를 늘릴 수 있습니다. 조인문 실행 속도를 최적화하세요

• 중복 정보를 통해 조인 수를 줄일 수 있습니다.

• 테이블 연결 수를 줄여보세요. 하나의 SQL 문당 5회를 초과하면 안 됩니다

인터뷰어: 조인 문은 상대적으로 성능을 많이 잡아먹는다고 요약할 수 있죠?

나: 네

인터뷰어: 왜요?

Buffer

나: 조인문을 실행할 때 비교 과정이 있어야 해요

인터뷰어: 네

나:두 테이블을 하나씩 비교하는 건 상대적으로 느리기 때문에 할 수 있어요. 두 테이블의 데이터를 순서대로 메모리 블록으로 읽어옵니다. MySQL의 InnoDB 엔진을 예로 들면 그림과 같이 다음 명령문을 사용하여 관련 메모리 영역을 확실히 찾을 수 있습니다show variables like '%buffer%'

join_buffer_size 크기가 영향을 미칩니다. 조인 문의 실행 성능

인터뷰어: 또 뭐가 있나요?

주요 전제

나:모든 프로젝트는 결국 온라인화되고 데이터 생성은 불가피합니다. 데이터 규모가 너무 클 수는 없습니다. small

인터뷰어: 그렇습니다

나:데이터베이스에 있는 대부분의 데이터는 결국 하드디스크에 저장되어 파일 형태로 저장됩니다.

MySQL의 InnoDB 엔진을 예로 들어보세요

• InnoDB는 페이지를 기본 IO 단위로 사용하며 각 페이지의 크기는 16KB입니다

• InnoDB는 각 테이블에 대한 저장소를 생성합니다. Data .ibd 파일

Verification

Me:이것은 연결할 테이블 수만큼 파일을 읽어야 한다는 뜻입니다. 인덱스를 사용할 수는 있지만 여전히 잦은 이동은 불가피합니다. 하드디스크

인터뷰어:즉, 자기헤드를 자주 움직이면 성능에 영향을 미치게 되겠죠?

나:네, 현재 오픈소스 프레임워크에서는 성능이 크게 향상됐다고 말하고 싶지 않나요? hbase, kafka와 같은 순차 읽기 및 쓰기를 통해 성능을 향상시켰나요?

인터뷰어: 그렇습니다. Linux에서 이를 최적화했다고 생각하시나요? 팁, 무료 명령을 다시 실행하여 살펴보세요

나: 이상합니다. 캐시 점유량 1.2G 이상

이미지 출처: https://www.linuxatemyram.com/

인터뷰어: 혹시

• 버프/ 캐시에 저장됨 무엇 이다?

• 버프/캐시가 왜 이렇게 많은 메모리를 차지하고, 사용 가능한 메모리도 있는데 아직 1.1G가 남아있나요?

• 버프/캐시가 차지한 메모리를 정리하기 위해 두 가지 명령을 사용할 수 있는데, 프로세스를 종료해야만 사용을 해제할 수 있는 이유는 무엇입니까?

핀, 신중하게 생각해 보셨나요

몇 분 후

나: 버프/캐시가 차지하는 메모리를 너무 가볍게 해제하는 것은 중요하지 않으며 이를 삭제해도 시스템 작동에 영향을 미치지 않는다는 의미입니다.

인터뷰어: 전혀 옳지 않습니다

나: 그럴까요? "CSAPP"(컴퓨터 시스템 심층 이해)의 한 문장이 생각납니다

메모리 계층 구조의 본질은 저장 장치의 각 계층이 하위 계층 장치의 캐시라는 것입니다

Inlayman's 즉, Linux는 메모리를 하드 디스크의 캐시로 취급합니다

관련 정보: http://tldp.org/LDP/sag/html/buffer-cache.html

인터뷰어: 이제 알았네요 포인트 질문에 어떻게 대답해야 할까요

나:나...

Join Algorithm

인터뷰어:한 번 더 기회를 달라고 하면 어떻게 하시겠습니까? Join 알고리즘을 구현하려면?

나: 색인이 없으면 중첩 루프가 종료됩니다. 색인이 있는 경우 색인을 사용하여 성능을 향상시킬 수 있습니다.

인터뷰어: join_buffer로 돌아가서, Join_buffer에 무엇이 저장되어 있다고 생각하시나요?

Me: 스캐닝 과정에서 데이터베이스는 테이블을 선택하고 반환하려는 데이터를 넣고 다른 테이블과 비교해야 합니다. .join_buffer

인터뷰어: 인덱스가 있을 때 어떻게 처리하나요?

나: 두 테이블의 인덱스 트리를 읽고 비교하면 됩니다. 인덱스 없는 처리 방법을 소개하겠습니다.

Nested Loop Join

Nested 루프만 한 번에 한 행의 데이터를 읽습니다. 즉, 외부 테이블에 100,000개의 데이터 행이 있고 내부 테이블에 100개의 데이터 행이 있으면 10,000,000번 읽어야 합니다(이 두 테이블의 파일이 있다고 가정). 작동되지 않음) 시스템은 이를 메모리에 캐시하므로 이를 콜드 데이터 테이블이라고 부릅니다.)

물론 현재 이 알고리즘을 사용하는 데이터베이스 엔진은 없습니다(너무 느림)

중첩 루프 차단

블록 블록, 즉 I/O 오버헤드를 줄이기 위해 매번 데이터 조각을 메모리로 가져오는 것을 말합니다

MySQL InnoDB는 인덱스를 사용할 수 없을 때 이 알고리즘을 사용합니다.

다음 두 테이블 t_a 및 t_b를 고려하세요.

인덱스를 조인 작업 수행에 사용할 수 없는 경우 InnoDB는 자동으로 차단 중첩 루프 알고리즘을 사용합니다.

요약

학교 다닐 때 데이터베이스 선생님이 데이터베이스 패러다임 시험을 가장 좋아하셨어요. , 중복될 수 없는 경우 가입하십시오. 실제로 성능에 영향을 미칩니다. Join_buffer_size를 늘리거나 솔리드 스테이트 드라이브로 변경해 보세요.

References

"컴퓨터 시스템에 대한 심층적인 이해" - 6장 메모리 계층
"리눅스 디스크 캐시를 이용한 실험과 재미" 저자는 하드 디스크 캐시가 프로그램 실행 성능에 미치는 영향을 설명하기 위해 몇 가지 예를 사용합니다.
"리눅스가 내 램을 먹었다》무료 매개변수 설명
리눅스에서 버퍼/페이지 캐시(디스크 캐시)를 지우는 방법 기사 시작 부분의 하위 질문 명령에 대한 설명
MySQL 실행 방법: 루트에서 MySQL 이해하기
Block MariaDB의 최고 루프 공식 문서는 Block-Nested-Loop 알고리즘의 구현을 설명합니다

위 내용은 코드 사양에서 SQL 문에 조인을 너무 많이 포함하지 않도록 요구하는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!