MYSQL 대량 기록 문제 최적화

요약:Mysql 의 성능 최적화 는 모두 sql 과 색인 을 최적화 시 켜 조회 성능 을 향상 시 키 는 것 을 중시 하고 대부분 제품 이나 사이트 가 직면 하 는 더 많은 높 은 병행 데이터 읽 기 문제 이다.그러나 데이터 장면 을 대량으로 기록 할 때 어떻게 최적화 해 야 합 니까?
오늘 은 주로 여러분 에 게 대량의 기록 장면 이 있 고 최 적 화 된 방안 을 소개 합 니 다.
전체적으로 말 하면 MYSQL 데이터베이스 기록 성능 은 주로 데이터베이스 자체 의 설정 과 운영 체제 의 성능,디스크 IO 의 성능 에 제한 을 받는다.주요 한 최적화 수단 은 다음 과 같은 몇 가 지 를 포함한다.
1.데이터베이스 파라미터 조정
（1） innodb_flush_log_at_trx_commit
기본 값 은 1 입 니 다.이것 은 데이터베이스 의 트 랜 잭 션 제출 설정 매개 변수 입 니 다.선택 할 수 있 는 값 은 다음 과 같 습 니 다.
0:로그 버퍼 는 1 초 에 한 번 씩 로그 파일 에 기록 되 고 로그 파일 을 디스크 작업 으로 새로 고침 하지만 한 트 랜 잭 션 에 서 는 아무런 작업 도 하지 않 습 니 다.
1:모든 트 랜 잭 션 을 제출 할 때 로그 버퍼 는 로그 파일 에 기록 되 어 로그 파일 을 디스크 작업 으로 새로 고 칩 니 다.
2:제출 할 때마다 로그 버퍼 는 파일 에 기록 되 지만 로그 파일 을 디스크 작업 으로 새로 고치 지 않 습 니 다.로그 파일 을 1 초 에 한 번 씩 새로 고 칩 니 다.
1 이 아 닌 값 으로 바 뀌 면 안전 하지 않 겠 냐 고 하 시 는 분 들 도 계 실 거 예요.안전성 은 다음 과 같다.
my sql 매 뉴 얼 에 서 는 업무 의 지속 성과 일치 성 을 확보 하기 위해 이 매개 변 수 를 1 로 설정 하 는 것 을 권장 합 니 다.출하 기본 값 은 1 이 고 가장 안전 한 설정 입 니 다.
innodbflush_log_at_trx_commt 와 syncbinlog 는 모두 1 일 때 가장 안전 합 니 다.my sqld 서비스 가 붕괴 되 거나 서버 호스트 crash 의 경우 binary log 는 가장 많은 문구 나 사 무 를 잃 어 버 릴 수 있 습 니 다.
그러나 이런 상황 에서 빈번 한 io 조작 을 초래 할 수 있 기 때문에 이 모델 도 가장 느 린 방식 이다.

innodbflush_log_at_trx_commt 를 0 으로 설정 하면 my sqld 프로 세 스 의 붕 괴 는 지난 1 초 동안 모든 트 랜 잭 션 데 이 터 를 잃 어 버 릴 수 있 습 니 다

innodbflush_log_at_trx_commt 는 2 로 설정 되 어 있 습 니 다.운영 체제 가 붕괴 되 거나 시스템 이 정전 되 었 을 때 만 지난 1 초 동안 모든 사무 데 이 터 를 잃 어 버 릴 수 있 습 니 다

같은 표 에 대해 c\#코드 를 통 해 시스템 업무 절차 에 따라 대량으로 삽입 하고 성능 은 다음 과 같다.

(a.같은 조건 에서:innodbflush_log_at_trx_commt=0,50W 줄 데 이 터 를 삽입 하 는 데 걸 리 는 시간 25.08 초;

(b.같은 조건 에서:innodbflush_log_at_trx_commt=1,50W 줄 데 이 터 를 삽입 하 는 데 걸 리 는 시간 17 분 21.91 초;

(c.같은 조건 에서:innodbflush_log_at_trx_commt=2,50W 줄 데 이 터 를 삽입 하 는 데 걸 리 는 시간 1 분 0.35 초..

결론:0 으로 설 정 된 경우 데이터 기록 이 가장 빠 르 고 데이터 베 이 스 를 기록 하 는 성능 을 신속하게 향상 시 킬 수 있 으 나 1 초 동안 의 데 이 터 를 잃 어 버 릴 수 있 습 니 다.
（2) temp_table_size,heap_table_size
이 두 매개 변 수 는 임시 표 temporary table 과 메모리 데이터베이스 엔진 memory engine 표 의 기록 에 영향 을 주 고 설정 이 너무 작 으 며 심지어 table is full 의 오류 메시지 가 나타 날 수 있 습 니 다.
실제 업무 상황 에 따라 기록 해 야 할 데이터 사용량 보다 많은 공간 크기 를 설정 해 야 합 니 다.
（3) max_allowed_packet=256M,net_buffer_length=16M，set autocommit=0
백업 과 복구 시 이 세 개의 인 자 를 설정 하면 백업 복구 속 도 를 날 릴 수 있 습 니 다!
（4) innodb_data_file_path=ibdata1:1G;ibdata2:64M:autoextend
표 공간 뒤의 autoextend 는 표 공간 을 자동 으로 확장 시 키 는 것 이 분명 합 니 다.기본 적 인 상황 에서 10M 만 있 지 않 고 대량의 데 이 터 를 기록 하 는 장면 에서 이 매개 변 수 를 확대 하 는 것 도 좋 습 니 다.
표 공간 을 늘 릴 때 한 번 에 가능 한 한 많은 표 공간 을 분배 하여 대량의 기록 을 할 때 자주 파일 확장 을 하지 않도록 합 니 다.
（5) innodb_log_file_size,innodb_log_files_in_group,innodb_log_buffer_size
트 랜 잭 션 로그 의 크기,로그 그룹 수,로그 캐 시 를 설정 합 니 다.기본 값 이 작 습 니 다.innodblog_file_size 기본 값 은 몇 십 M,innodblog_files_in_group 기본 값 은 2 입 니 다.
그러나 innodb 에 서 는 데 이 터 는 캐 시 를 먼저 쓰 고 트 랜 잭 션 로 그 를 쓴 다음 데이터 파일 을 쓴다.설정 이 너무 작 아서 대량의 데 이 터 를 기록 하 는 장면 에서 데이터 베 이 스 를 자주 촉발 하 는 검사 점 을 초래 할 수 있 습 니 다.로그 에 있 는 데 이 터 를 디스크 데이터 파일 에 기록 하 십시오.버퍼 를 자주 새로 고치 고 로 그 를 전환 하면 대량의 기록 데이터 성능 이 떨 어 집 니 다.
물론 너무 크게 설치 해 서 는 안 된다.대회 가 지나 면 데이터 베 이 스 를 이상 하 게 지연 시 킬 때 데이터 베 이 스 를 다시 시작 할 때 로그 에 기록 되 지 않 은 더러 운 데 이 터 를 읽 고 redo 를 진행 하 며 데이터 베 이 스 를 복원 합 니 다.너무 크 면 회복 시간 이 길 어 집 니 다.복구 시간 이 사용자 가 예상 한 복구 시간 을 훨씬 초과 하면 반드시 사용자 의 불평 을 불 러 일 으 킬 것 이다.
이 설정 은 화 웨 이 클 라 우 드 의 데이터베이스 기본 설정 을 참고 할 수 있 습 니 다.화 웨 이 클 라 우 드 2 핵 4G 환경 에서 기본 설정 인 buffer:16M,logfile_size:1G--차이 가 많 지 않 습 니 다.my sql 공식 건의 에 따라 전체 메모리 의 25%에 달 했 습 니 다.로그 그룹 filesin_그룹 은 4 조로 설정 합 니 다.

2 핵 4G 처럼 낮은 하드웨어 설정 은 매개 변수 설정 의 합 리 성 으로 인해 초당 수천 번,분당 8 만 번 의 읽 기와 쓰기 요청 을 견 딜 수 있 습 니 다.
만약 에 데 이 터 를 읽 는 장면 보다 훨씬 많이 쓰 거나 파 라 메 터 를 마음대로 바 꾸 는 장면 이 편리 하 다 면 대량의 데 이 터 를 가 져 오고 조정 할 수 있 습 니 다.logfile_size 조정 이 더 크 면 innodb 에 도달 할 수 있 습 니 다.buffer_pool_사이즈 의 25~100%.
（6) innodb_buffer_pool_size 는 MySQL Innodb 의 사용 가능 한 캐 시 크기 를 설정 합 니 다.이론 적 으로 최대 서버 총 메모리 의 80%로 설정 할 수 있 습 니 다.
큰 값 을 설정 할 수록 작은 값 을 설정 한 기록 보다 성능 이 좋 습 니 다.예 를 들 어 위의 매개 변수 innodblog_file_size 는 innodb 참조buffer_pool_size 크기 로 설 정 했 습 니 다.
（7) innodb_thread_concurrency=16
옛 이름 은 생각 하고 병발 라인 수 를 제어 하 며 이론 적 으로 라인 수가 많 을 수록 당연히 기록 이 빨 라 진다.물론 너무 큰 공식 건의 가 CPU 핵 수의 두 배 정도 가 적당 하 다 고 설정 해 서 는 안 된다.
（8) write_buffer_size
단일 세 션 이 한 번 에 기록 하 는 캐 시 크기 를 제어 합 니 다.기본 값 은 4K 정도 이 며,일반적으로 조정 하지 않 아 도 됩 니 다.그러나 잦 은 대량 기록 장면 에 서 는 2M 으로 조정 해 볼 수 있 습 니 다.기록 속도 가 어느 정도 향상 되 는 것 을 발견 할 수 있 습 니 다.
（9) innodb_buffer_pool_instance
기본 값 은 1 입 니 다.주로 메모리 버퍼 의 개 수 를 설정 합 니 다.쉽게 말 하면 읽 기와 쓰기 innodb 를 제어 합 니 다.buffer_pool 의 개수.
대량의 양 을 기록 하 는 장면 에서 도 이 매개 변 수 를 확대 할 수 있 고 현저 한 성능 향상 을 가 져 올 수 있다.
（10) bin_log
바 이 너 리 로 그 는 보통 데이터베이스 의 모든 추가 삭제 작업 을 기록 합 니 다.그러나 대량의 데이터 유도,예 를 들 어 데이터 베 이 스 를 복원 할 때 bin 을 임시로 닫 아 도 됩 니 다.log,바 이 너 리 로그 에 대한 기록 을 끄 고 데이터 파일 만 기록 하도록 합 니 다.데이터 복 구 를 신속하게 완료 하고 끝 난 후에 시작 합 니 다.
2.디스크 IO 를 줄 이 고 디스크 읽 기와 쓰기 효율 향상
다음 과 같은 방법 을 포함한다.
(1):데이터베이스 시스템 구조 최적화
a:복사 하기;
예 를 들 어 하나의 더 블 메 인 을 배치 하고 더 블 메 인 모델 배 치 는 서로 백업 하기 위해 데이터 안전 을 확보 할 수 있 습 니 다.서로 다른 업무 시스템 은 서로 다른 데이터 베이스 서버 를 연결 하고 ngnix 또는 keepalive 자동 전환 기능 과 결합 하여 부하 균형 과 고장 시 자동 으로 전환 합 니 다.
이러한 구조 최 적 화 를 통 해 업무 시스템 을 분산 시 키 는 읽 기와 쓰기 IO 는 한 대의 서버 에서 여러 대의 서버 까지 마찬가지 로 한 대의 데이터 베 이 스 를 기록 하 는 속 도 를 높 일 수 있다.
b:읽 기와 쓰기 분리 하기
1 에서 고려 해 야 할 문제 와 마찬가지 로 단일 서버 의 디스크 IO 를 줄 일 수 있 고 서버 에 있 는 백업 작업 을 예비 서버 로 옮 겨 메 인 서버 의 IO 압력 을 줄 여 기록 성능 을 향상 시 킬 수 있다.
(2):하드웨어 최적화
a:자원 이 제 한 된 상황 에서 배 치 를 설치 할 때 운영 체제 에 여러 개의 디스크 가 있어 야 합 니 다.응용 프로그램,데이터베이스 파일,로그 파일 등 을 서로 다른 디스크 에 분산 시 켜 저장 하고 각 디스크 의 IO 를 줄 여 단일 디스크 의 기록 성능 을 향상 시 킵 니 다.
b:고체 하 드 디스크 SSD 사용
만약 에 자원 이 SSD 로 저장 할 수 있다 면 SSD 는 고속 으로 기록 하 는 특성 을 가지 고 모든 디스크 IO 작업 도 현저히 향상 시 킬 수 있다.
물론 더 많은 하드웨어 나 소프트웨어 최적화 방법 이 있 으 니 여기 서 일일이 열거 하지 않 겠 다.
여기 서 MYSQL 대량 기록 문제 최적화 에 관 한 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 관련 MYSQL 대량 기록 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 바 랍 니 다!