Mysql 임시 표 및 파 티 션 표 차이 상세 설명

임시 테이블 과 메모리 테이블
메모리 테이블 은 메모리 엔진 을 사용 하 는 테이블 을 가리 키 며,테이블 문법 은 create table...engine=memory 입 니 다.이 표 의 데 이 터 는 메모리 에 저 장 됩 니 다.시스템 이 재 부팅 될 때 비 워 지지 만 표 구 조 는 그대로 있 습 니 다.이 두 가지 특성 이 비교적'이상 하 다'는 것 을 제외 하고 다른 특징 에서 볼 때 이것 은 정상 적 인 표 이다.
임시 표,각종 엔진 유형 을 사용 할 수 있 습 니 다.InnoDB 엔진 이나 MyISAM 엔진 의 임시 시 계 를 사용한다 면 데 이 터 를 쓸 때 디스크 에 쓴다.물론 임시 시계 도 메모리 엔진 을 사용 할 수 있다.
임시 테이블 특성

건 표 문법 은 create temporary table..

4.567917.임시 표 는 session 만 만 들 수 있 고 다른 스 레 드 에 서 는 볼 수 없습니다.따라서 그림 에서 session A 가 만 든 임시 표 t 는 session B 에 대해 보이 지 않 습 니 다임시 표 는 일반 표 와 동명 일 수 있다

session A 에 같은 이름 의 임시 표 와 일반 표 가 있 을 때 show create 어 는 63750°이 고 삭제 하고 검사 어 는 63750°에 방문 하 는 것 은 임시 표 입 니 다

show tables 명령 은 임시 표를 표시 하지 않 습 니 다

임시 표 는 session 접근 만 만 만 들 수 있 기 때문에 이 session 이 끝 날 때 임시 표 가 자동 으로 삭 제 됩 니 다.바로 이 특성 때문에 임시 표 는 join 최적화 장면 에 특히 적합 하 다.
create temporary table temp_t like t1;
alter table temp_t add index(b);
insert into temp_t select * from t2 where b>=1 and b<=2000;
select * from t1 join temp_t on (t1.b=temp_t.b);
세 션 과 다른 임시 표 는 이름 을 바 꿀 수 있 습 니 다.여러 세 션 이 동시에 join 을 최적화 하면 표 이름 이 중복 되 어 표 작성 에 실패 하 는 문 제 를 걱정 할 필요 가 없습니다.데이터 삭제 문 제 를 걱정 할 필요 가 없습니다.만약 에 일반 표를 사용 하면 절차 수행 과정 에서 클 라 이언 트 가 이상 하 게 끊 기거 나 데이터 베이스 가 이상 하 게 재 부팅 되 거나 사랑 의 중간 과정 에서 생 성 된 데이터 표를 정리 해 야 한다.임시 시 계 는 자동 으로 회수 되 기 때문에 이 추가 작업 이 필요 하지 않 습 니 다.임시 테이블 의 응용
라 이브 러 리 테이블 시스템 의 라 이브 러 리 조회
일반 라 이브 러 리 분 표 의 장면 은 논리 적 인 큰 시 계 를 서로 다른 데이터 베이스 에 분산 시 키 는 것 이다.예 를 들 면.큰 표 ht 를 필드 f 에 따라 1024 개의 분 표 로 나 눈 다음 32 개의 데이터 베 이 스 를 실제 63925℃에 분포 합 니 다.

파 티 션 key 의 선택 은'크로스 라 이브 러 리 와 크로스 표 조회 감소'를 근거 로 한다.대부분의 언어 가 f 의 등가 조건 을 포함 하고 있다 면 f 로 파 티 션 키 를 만들어 야 합 니 다.이렇게 하면 proxy 라 는 층 에서 SQL 어 를 분석 한 후에 이 단 어 를 63750°토 르 에서 어느 분 표 로 조회 하 는 지 확인 할 수 있 습 니 다.예 를 들 면
select v from ht where f=N;
이때 우 리 는 분 표 규칙(예 를 들 어 N%1024)을 통 해 필요 한 데이터 가 어느 분 표 에 놓 여 있 는 지 확인 할 수 있다.이런 말 은 63750℃이 고 하나의 분 표 만 방문 해 야 하 며 분 라 이브 러 리 분 표 방안 에서 가장 환영 하 는 말 입 니 다.63750℃의 형식 입 니 다.
그러나 이 표 에 또 다른 색인 k 가 있 고 검색 어 는 63750℃입 니 다.
select v from ht where k >= M order by t_modified desc limit 100;
이 때 조회 조건 은 63977 면 에 파 티 션 필드 f 를 사용 하지 않 았 기 때문에 모든 파 티 션 에서 조건 을 만족 시 키 는 모든 행 위 를 찾 은 다음 에 order by 작업 을 통일 할 수 밖 에 없습니다.이런 상황 에서 비교적 자주 사용 하 는 토 르 두 가지 가 있다.
proxy 계층 의 프로 세 스 코드 에서 정렬 을 실현 합 니 다.proxy 엔 드 에 대한 압력 은 63882℃입 니 다.특히 메모리 부족 과 CPU 병목 문제 가 발생 할 수 있 습 니 다.
각 라 이브 러 리 에서 얻 은 데 이 터 를 MySQL 의 실제 표 에 모 은 다음 에 이 총 63925℃에서 논리 적 인 조작 을 합 니 다.
집계 라 이브 러 리 에 임시 표 temp 만 들 기ht,표 는 세 개의 필드 v,k,t 를 포함 합 니 다.modifified；
각 지점 에서 행동 하 다.
select v,k,t_modified from ht_x where k >= M order by t_modified desc limit 100;
라 이브 러 리 실행 결 과 를 temp 에 삽입 합 니 다.ht 표 중;
집행 하 다.
select v from temp_ht order by t_modified desc limit 100;
왜 임시 표 는 이름 을 바 꿀 수 있 습 니까?
create temporary table temp_t(id int primary key)engine=innodb;
이 단 어 를 실행 할 때 MySQL 은 이 InnoDB 표 에 frm 파일 저장 표 구조 정 의 를 만 들 고 표 데 이 터 를 저장 할 곳 도 있어 야 합 니 다.
이 frm 파일 은 임시 파일 디 렉 터 리 에 놓 여 있 습 니 다.파일 이름 의 접 두 사 는'frm'이 고 접 두 사 는'\#sql{프로 세 스 id} {'입 니 다.스 레 드 id}번호select@@tmpdir 명령 을 사용 하여 실제 파일 디 렉 터 리 를 표시 할 수 있 습 니 다.

이 프로 세 스 의 프로 세 스 번 호 는 1234 이 고 session A 의 스 레 드 id 는 4 이 며 session B 의 스 레 드 id 는 5 입 니 다.그래서 session A 와 session B 가 만 든 임시 테이블 은 디스크 에 있 는 파일 의 이름 을 바 꿀 수 없습니다.
MySQL 유지 데이터 시트 는 사물 의 사랑 에 파일 이 있어 야 하 는 것 을 제외 하고 메모리 에 도 메커니즘 차이 가 다른 표 가 있 습 니 다.모든 표 는 하나의 table 에 대응 합 니 다.def_key。 임시 표 에 대해 tabledef_key 는'라 이브 러 리+표 이름'을 바탕 으로'server'를 추가 했다.id+thread_id”。
즉,session A 와 session B 가 만 든 두 개의 임시 표 t1,그들의 tabledef_키 가 다 르 고 디스크 파일 이름 도 다 르 기 때문에 병존 할 수 있 습 니 다.
파 티 션 시트 의 엔진 계층 행동

ATE	TABLE	`t`	(
		`ftime`	datetime	NOT	NULL,
		`c`	int(11)	DEFAULT	NULL,
		KEY	(`ftime`)
)	ENGINE=InnoDB	DEFAULT	CHARSET=latin1
PARTITION	BY	RANGE	(YEAR(ftime))
Û ॔ګդᎱ
B
 (PARTITION	p_2017	VALUES	LESS	THAN	(2017)	ENGINE	=	InnoDB,
 	PARTITION	p_2018	VALUES	LESS	THAN	(2018)	ENGINE	=	InnoDB,
 	PARTITION	p_2019	VALUES	LESS	THAN	(2019)	ENGINE	=	InnoDB,
 PARTITION	p_others	VALUES	LESS	THAN	MAXVALUE	ENGINE	=	InnoDB);
 insert	into	t	values('2017-4-1',1),('2018-4-1',1);

시 계 를 초기 화 할 때 두 줄 의 데이터 만 삽입 되 었 습 니 다.session A 의 selection 문 구 는 ftime 라 는 두 기록 사이 의 간격 에 자 물 쇠 를 추가 하고 간격 과 잠 금 상 태 는 그림 과 같 습 니 다.

즉,2017-4-1 과 2018-4-1 이라는 두 기록 사이 의 간극 이 잠 겨 있 으 면 session B 의 두 삽입 문 구 는 모두 잠 금 대기 상태 에 들 어가 야 한 다 는 것 이다.그러나 효과 적 으로 볼 때 첫 번 째 insert 문 구 는 성공 적 으로 실 행 될 수 있 습 니 다.엔진 에 있어 p2018 과 p2019 는 서로 다른 표 이기 때문에 2017 의 다음 기록 은 2018-4-1 이 아니 라 p2018 중의 supremum 이기 때문에 t1 시간 에 색인 은 그림 과 같 습 니 다.

파 티 션 시트 의 규칙 으로 인해 session A 는 p2018 만 작 동 했 습 니 다.session B 는 2018-2-1 을 삽입 하 는 것 은 가능 하지만 2017-12-1 을 기록 하려 면 session A 의 간극 자 물 쇠 를 기 다 려 야 합 니 다.
MYISAM 엔진 에 대해:

session A 에서 sleep 는 100 초 입 니 다.my isam 은 시계 자물쇠 만 지원 하기 때문에 이 update 는 전체 표 t 의 읽 기 를 잠 글 것 입 니 다.그러나 결 과 는 B 의 첫 번 째 문 구 는 실행 할 수 있 고 두 번 째 문 구 는 잠 금 대기 상태 에 들 어 갑 니 다.
이것 은 my isam 시계 자 물 쇠 는 엔진 층 에서 만 이 루어 집 니 다.session A 에 추 가 된 시계 자 물 쇠 는 p2018 에 있 기 때문에 파 티 션 에서 실 행 된 조회 만 막 고 다른 파 티 션 의 조회 에 영향 을 받 지 않 습 니 다.이렇게 보면 분 구 표 는 괜 찮 은 데 왜 사용 하지 않 습 니까?우리 가 분 구 표를 사용 하 는 이 유 는 표 가 너무 크 기 때 문 입 니 다.그러면 분 구 표를 사용 하지 않 고 수 동 으로 표를 나 누 는 방식 을 사용 해 야 합 니 다.
수 동 분 표 생 성 t2017,t_2018,t_2019,즉 업데이트 가 필요 한 모든 분 표를 찾 아 순서대로 실행 하 는 것 입 니 다.이것 은 분 구 표 와 실질 적 인 차이 가 없습니다.둘 중 하 나 는 server cing 에서 어느 분 구 를 사용 할 지 결정 하고 하 나 는 응용 층 코드 에 의 해 어느 분 표를 사용 할 지 결정 하기 때문에 엔진 층 에서 볼 때 실제 적 인 차이 가 없습니다.사실 주요 차이 점 은 server 층:시 계 를 여 는 행위 입 니 다.
파 티 션 정책
파 티 션 시트 를 처음 방문 할 때마다 my sql 은 모든 파 티 션 을 한 번 방문 해 야 합 니 다.파 티 션 이 많 으 면 1000 개 를 찾 았 을 때 my sql 이 시 작 될 때 openfiles_limit 는 기본적으로 1024 입 니 다.그러면 방문 표 에서 모든 파일 을 열 었 기 때문에 상한 선 을 초과 하여 오 류 를 보고 합 니 다.
my sia 가 사용 하 는 파 티 션 정책 은 유 니 버 설 파 티 션 정책 이 되 었 으 며,파 티 션 에 접근 할 때마다 server 계층 이 제어 합 니 다.비교적 심각 한 성능 문제 가 있다.
innodb 엔진 은 로 컬 파 티 션 전략 을 도입 하여 innodb 내부 에서 파 티 션 을 여 는 행 위 를 스스로 관리 합 니 다.
파 티 션 시트 의 server 계층 행동
server 층 에서 볼 때 하나의 파 티 션 표 는 하나의 표 입 니 다.

B 는 2017 구역 만 작 동 하지만 A 가 전체 표 t 의 mdl 자 물 쇠 를 가지 고 있어 B 의 alter 문 구 를 막 았 다.일반 분 표를 사용한다 면 다른 분 표 의 검색 어 와 MDL 충돌 이 일어나 지 않 습 니 다.
소결:

my sql 은 파 티 션 표를 처음 열 때 모든 파 티 션 을 방문 해 야 합 니 다

server 층 에서 이것 이 같은 표 라 고 생각 하기 때문에 모든 구역 의 공용 MDL 잠 금

4.567917.엔진 층 에 서 는 이것 이 서로 다른 시계 라 고 생각 하기 때문에 MDL 잠 금 후에 파 티 션 표 규칙 에 따라 필요 한 파 티 션 만 방문 합 니 다파 티 션 테이블 응용 장면
분 구 표 의 장점 은 업무 가 투명 하고 사용자 분 표 에 비해 분 구 표 의 업무 코드 를 사용 하 는 것 이 더욱 간결 하 며 분 구 표 는 역사 데 이 터 를 편리 하 게 정리 할 수 있다 는 것 이다.
alter table t drop partition 작업 은 파 티 션 파일 을 삭제 하 는 것 입 니 다.효 과 는 drop 과 유사 합 니 다.delete 에 비해 속도 가 빠 르 고 시스템 에 미 치 는 영향 이 적 습 니 다.
이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.