MySQL 성능 최적화의 5가지 차원

MySQL 성능 최적화의 5가지 차원

1. 데이터베이스 연결 구성 최적화

1. 서버가 해야 할 일은 가능한 한 많은 클라이언트 연결을 허용하는 것입니다. 아마도 오류 1040: 연결이 너무 많습니까? 단지 서버 측의 연결 수가 충분하지 않다는 것입니다.
2. 클라이언트가 할 수 있는 일은 서버와의 연결 설정 횟수를 최소화하는 것입니다. 이미 설정된 연결을 사용할 수 있으면 사용하십시오. SQL 문을 실행할 때마다 새로운 연결을 생성하지 마십시오. 두 리소스 모두 서버와 클라이언트가 압도당할 것입니다.

1. 최대 서버 연결 수 최적화 구성

서버가 해야 할 일은 가능한 한 많은 클라이언트 연결을 허용하는 것입니다. 아마도 오류 1040: 연결이 너무 많습니까? 단지 서버 측의 연결 수가 충분하지 않다는 것입니다.
클라이언트가 할 수 있는 일은 서버와 연결을 설정하는 횟수를 최소화하는 것입니다. 기존 연결을 사용할 수 있으면 사용하십시오. SQL 문이 실행될 때마다 새 연결을 생성하지 마십시오. 두 서버의 리소스 그리고 클라이언트는 압도당할 것이다.

해결책은 연결 풀을 사용하여 연결을 재사용하는 것입니다.
연결 부족 문제는 두 가지 측면에서 해결할 수 있습니다:
(1) 방법 1: 사용 가능한 연결 수를 늘리고 환경 변수 max_connections를 수정합니다. 기본적으로 서버의 최대 연결 수는 151입니다. mysql>
show Variables like ' max_connections';
± ---±------+
| 변수_이름 | 값 |
±---------------- ±--- ---+
| max_connections | 151 |
±---±------+
세트 내 1행(0.01초)

set GLOBAL max_connections=1000; #최대 연결 수를 1000으로 수정

(2) 방법 2
/etc/my.cnf #
데이터베이스 구성 파일에 max_connections=1500 구성을 추가하고 # 최대 연결 수를 1500으로 수정한
후 데이터베이스를 다시 시작합니다.

2. 비활성 연결 해제

적시에 비활성 연결을 해제합니다. 시스템의 기본 클라이언트 시간 초과는 28800초(8시간)입니다. 이 값을 더 작게 조정할 수 있습니다.
mysql> show Variable like 'wait_timeout';
±------------ --- -±------+
| 변수 이름 | 값 |
±---------------±------+
| wait_timeout | 28800 |
±---- --- -------±------+
1줄 세트 (0.01초)

구성 파일 수정
/etc/my.cnf
Interactive_timeout=18800
wait_timeout=18800

데이터베이스 다시 시작

2. 아키텍처 최적화

1. 캐시를 활용하라

(1) 데이터가 특별히 효과적이지 않은 경우(일일 보고서와 같이 매 순간 변경되지 않는 경우) 이러한 데이터를 캐시 시스템에 저장하고 데이터의 캐시 유효 기간 동안 직접 검색할 수 있습니다. 캐시 시스템 데이터베이스에서 데이터를 얻으면 데이터베이스에 대한 부담을 줄이고 쿼리 효율성을 높일 수 있습니다.

2. 읽기와 쓰기의 분리

(1) 여러 개의 데이터베이스 서버를 동시에 사용할 수 있으며, 그 중 하나를 마스터 노드라고 하는 팀 리더로 설정하고, 다른 노드를 슬레이브라고 하는 팀 구성원으로 설정합니다. 사용자는 마스터 노드에만 데이터를 쓰고, 읽기 요청은 다양한 슬레이브 노드로 분산됩니다. 이 솔루션을 읽기-쓰기 분리라고 합니다.

(2) 클러스터를 사용하면 여러 노드 간의 데이터 일관성을 유지하기 위해 마스터-슬레이브 복제 문제가 불가피하게 발생합니다.
Binlog는 MySQL 마스터-슬레이브 복제 기능을 구현하는 핵심 구성 요소입니다.
① 슬레이브 측 IO 스레드가 마스터 측 binlog(바이너리 로그) 스레드에 요청을 보냅니다.
② 마스터 측 binlog 덤프 스레드가 바이너리 로그 정보(파일 이름 및 위치 정보)를 획득하여 슬레이브에 보냅니다. -side IO 스레드
③. 슬레이브 측 IO 스레드에서 얻은 내용을 차례로 슬레이브 측 릴레이 로그(relay log)에 쓰고, 마스터 측의 bin-log 파일명과 위치를 http:/에 기록한다. /master.info ④.
슬레이브 측의 SQL 스레드는 릴레이 로그의 내용이 업데이트되었음을 ​​감지하면 릴레이 로그의 업데이트된 내용을 구문 분석하고 이러한 작업을 수행하여 마스터 데이터와의 일관성을 유지합니다.

3. 하위 라이브러리 및 하위 테이블

데이터베이스 및 테이블 샤딩 요약: 요약: 수평 샤딩은 주로 스토리지 병목 현상을 해결하기 위한 것이고, 수직 샤딩은 주로 동시성 압박을 줄이기 위한 것입니다.

(1) 수직 샤딩:
샤딩 데이터베이스와 샤딩 테이블에서 노드의 의미는 상대적으로 넓으며, 데이터베이스를 노드로 사용하면 샤딩 데이터베이스, 단일 테이블을 노드로 사용하면 샤딩 테이블이다. .
하위 라이브러리 및 테이블 하위 구분은 수직 하위 데이터베이스, 수직 하위 테이블, 수평 하위 데이터베이스 및 수평 하위 테이블로 구분됩니다.

하나의 데이터베이스를 기반으로 여러 개의 수직적 절단을 하여 비즈니스 로직에 따라 여러 개의 데이터베이스로 분할하는 것이 수직형 하위 데이터베이스입니다.

(2) 수직 테이블 분할
수직 테이블 분할은 하나의 테이블에서 하나(또는 여러 개의 절단)를 수직으로 절단하여 테이블의 여러 단어를 여러 개의 작은 테이블로 분할하는 작업으로, 이 작업은 특정 비즈니스에 따라 수행되어야 합니다. , 일반적으로 자주 사용되는 필드(핫 필드)는 테이블로 나누고, 자주 사용하지 않거나 즉시 사용하지 않는 필드(콜드 필드)는 테이블로 나누어 쿼리 속도를 향상시킵니다.

(3) 수평 테이블 분할:
단일 테이블의 데이터를 특정 규칙(전문 용어로는 샤딩 규칙이라고 함)에 따라 여러 데이터 테이블에 저장하고, 데이터 테이블에 하나의 나이프(또는 여러 개의 나이프)를 수평으로 적용하는 것, 이것이 수평 테이블 파티셔닝입니다. .

(4) 수평 하위 데이터베이스
수평 하위 데이터베이스는 단일 데이터베이스를 수평으로 자르는 것으로, 수평 테이블 분할이 수반되는 경우가 많습니다.

4. 메시지 큐

일반적으로 사용자 요청은 데이터베이스에 직접 액세스하지만, 동시에 온라인 사용자 수가 매우 많으면 데이터베이스를 압도할 가능성이 매우 높습니다(연예인이 부정 행위를 하거나 관계를 발표할 때 웨이보의 상태 참조).
이 경우 메시지 큐를 사용하면 데이터베이스에 대한 부담을 줄일 수 있으며 동시에 사용자 요청이 아무리 많아도 먼저 메시지 큐에 저장되고 시스템은 메시지의 요청을 소비합니다. 순서대로 줄을 서세요.

3. SQL 분석 및 최적화

1. 느린 쿼리

느린 쿼리는 매우 느리게 실행되는 쿼리입니다. MySQL에 어떤 느린 쿼리가 있는지 알아야만 대상 최적화를 수행할 수 있습니다.
느린 쿼리 로그를 켜면 성능 비용이 발생하기 때문에 MySQL에서는 기본적으로 느린 쿼리 로그 기능을 끄는데, 현재 느린 쿼리 상태를 보려면 다음 명령어를 사용하세요.
'slow_query%'와 같은 변수 표시;
mysql> 'slow_query%'와 같은 변수 표시;
±---------±------------ ------------------+
| 변수_이름 | 값 |
±------------ ---- ----±---------------+
| Slow_query_log | OFF |
| Slow_query_log_file | /var/lib/mysql/9e74f9251f6c-slow.log |
±---------±--------- ------- ----------+
2 행 세트(0.00초)
Slow_query_log는 느린 쿼리 로그가 현재 활성화되어 있는지 여부를 나타냅니다. Slow_query_log_file은 느린 쿼리 로그의 저장 위치를 ​​나타낸다.
위의 두 변수 외에 "느린" 지표가 무엇인지, 즉 쿼리를 실행하는 데 걸리는 시간이 느린 쿼리로 간주되는지도 확인해야 합니다. 기본값은 10S입니다. 0으로 변경하면 , '%long_query%'와 같은 모든 SQL 쇼 변수가 기록됩니다
.';
mysql>은 '%long_query%'와 같은 변수를 표시합니다.
±---±------------+
| 변수명 | 가치 |
±---±------------+
| long_query_time | 10.000000 |
±---±------------+
1행 세트(0.00초)

2. 느린 쿼리 로그 열기

(1) 방법 1: my.cnf 구성 파일을 수정합니다.
이 수정 사항은 시스템을 다시 시작한 후에도 계속 적용됩니다.

#느린 쿼리 로그 활성화 여부
Slow_query_log=ON
long_query_time=2
Slow_query_log_file=/var/lib/mysql/slow.log

(2) 방법 2: 매개변수를 동적으로 수정(재시작 후 무효)
mysql> set @@global.slow_query_log=1;
Query OK, 0 행 영향 받음(0.06초)
mysql> set @@global.long_query_time=2;
Query OK, 0 영향을 받는 행(0.00초)

3. 느린 쿼리 로그 분석

MySQL은 느린 로그 파일을 저장할 뿐만 아니라 느린 로그 쿼리 도구인 mysqldumpslow도 제공합니다. 이 도구를 시연하기 위해 먼저 느린 쿼리를 구성합니다: mysql> SELECT sleep(5); 느린 쿼리 수 보기 log
records
:
SHOW GLOBAL STATUS LIKE '%Slow_queries%';
그런 다음 가장 많은 시간이 걸리는 느린 쿼리를 쿼리합니다.

mysqldumpslow -st -t 1 -g 'select' /var/lib/mysql/9e74f9251f6c-slow.log
/var/lib/mysql/9e74f9251f6c-slow.log에서 mysql 느린 쿼리 로그 읽기
횟수: 1 시간=10.00초(10초) ) Lock=0.00s (0s) Rows=1.0 (1), root[root]@localhost
SELECT sleep(N)
그 중
Count: 이 SQL이 실행된 횟수
Time: 실행 시간 누적 괄호 안의 시간은
잠금: 잠금 시간, 괄호 안은 누적 시간
행: 반환된 레코드 수, 괄호 안은 누적 개수입니다.

cat /var/lib/mysql/data/slow.log
SHOW 프로필 SQL Query 소요 시간 보기
SQL 전체 Life Cycle의 소요 시간은
Query_ID를 통해 알 수 있음 연결 - 서비스까지 4계층 구조의 전체 수명 - 엔진 - 스토리지 주기 시간
SHOW profile CPU, BLOCK IO FOR QUERY 4;
사용 가능한 매개변수 유형:
ALL # 모든 오버헤드 정보 표시
BLOCK IO # 블록 IO 관련 오버헤드 표시
CONTEXT SWITCHES # 컨텍스트 스위치 관련 오버헤드
CPU # CPU 관련 오버헤드 정보 표시
IPC # Display 송수신 관련 오버헤드 정보 표시
MEMORY # 메모리 관련 오버
헤드 정보 표시 PAGE FAULTS # 페이지 폴트 관련 오버헤드 정보 표시
SOURCE # Source_function, Source_file, Source_line 관련 오버헤드 정보 표시
SWAPS # Swap 횟수 관련 오버헤드 정보 표시

4. 실행 중인 스레드 보기

show full processlist를 실행하여 MySQL에서 실행 중인 모든 스레드를 보고, 스레드의 상태와 실행 시간을 보고, 실행 시간이 긴 사이트를 찾아 직접 종료할 수 있습니다.
그중
Id: 스레드의 고유 식별자 Id를 사용하여 지정된 스레드를 종료할 수 있음
User: 이 스레드를 시작한 사용자 일반 계정은 자신의 스레드만 볼 수 있음
Host: 연결을 시작한 IP 및 포트 .
db: 스레드가 운영하는 데이터베이스
Command: 스레드의 Command
Time: 작업 기간(초)
State: 스레드의 상태
Info: SQL 문의 처음 100자

5. 서버 실행 상태 확인

300개 이상의 레코드를 얻기 위해 show status 명령을 직접 사용하는 것은 우리를 놀라게 할 것이므로 요청 시 일부 상태 정보를 "볼" 수 있기를 바랍니다. 이때 show status 문 뒤에 해당 like 절을 추가할 수 있습니다. 예를 들어 MySQL이 시작된 후 현재 실행 시간을 보려면 다음 명령문을 실행할 수 있습니다.
SHOW STATUS 명령을 사용하여 서버의 상태 정보를 봅니다.
구체적인 명령은 다음과 같습니다. 전역 추가는 전역 변수를 나타냅니다.
1) select 문 실행 횟수 확인:
'com_select'와 같이 [global] 상태 표시
2) insert 문의 실행 횟수 확인:
'com_insert'와 같은 [global] 상태 표시
3) 실행 횟수 확인 업데이트 문:
show [global] ] status like 'com_update';
4) 삭제 문 실행 횟수 보기:
show [global] status like 'com_delete';
5) MySQL에 연결을 시도하는 연결 수 보기(연결 여부에 관계 없음) 성공 여부):
'connections'와 같은 상태 표시;
6) 스레드 캐시의 스레드 수 보기:
'threads_cached'와 같은 상태 표시;
7) 현재 열려 있는 연결 수 보기:
'threads_connected'와 같은 상태 표시;
8 ) 연결을 처리하기 위해 생성된 스레드 수를 확인합니다.
'threads_created'와 같은 상태 표시;
9) 활성화된(비휴면) 스레드 수 보기:
'threads_running'과 같은 상태 표시;
10) 즉시 획득된 테이블 잠금 수 보기:
'table_locks_immediate'와 같은 상태 표시;
11) 보기 불가 즉시 획득된 테이블 잠금 수입니다. 값이 높고 성능 문제가 있는 경우 먼저 쿼리를 최적화한 다음 테이블을 분할하거나 복제를 사용해야 합니다.
'table_locks_waited'와 같은 상태 표시;
12) Slow_launch_time 초보다 오래 생성된 스레드 수 보기:
표시 status like 'slow_launch_threads' ;
13) 쿼리 시간이 long_query_time 초를 초과하는 쿼리 수 확인:
'slow_queries' 같은 상태 표시;
14) 이 시작 후 MySQL의 실행 시간 확인(단위: 초):
'uptime' 같은 상태 표시 ; 15) 'last_query_cost'와 같은
이전 쿼리 표시 상태의 비용을 확인합니다. 16) 'qcache%'와 같은 쿼리 캐시 정보 표시 상태를 확인합니다.

6. 스토리지 엔진의 실행 상태 보기
(1) SHOW ENGINE은 트랜잭션이 보유한 테이블 잠금 및 행 잠금 정보, 트랜잭션의 잠금 대기 상태, 스레드 세마포 대기, 스레드 세마포 대기 등 스토리지 엔진의 현재 실행 정보를 표시하는 데 사용됩니다. 파일 IO 요청, 버퍼 풀 통계 및 기타 데이터.
(2) InnoDB 버전을 쿼리하여
'innodb_version'\G와 같은 변수를 표시
하거나 information_schema.plugins에서 *를 선택하고
mysql> 'innodb_version'\G와 같은 변수를 표시합니다.
*************** ************ 1. 행 ***************************
Variable_name: innodb_version
값: 5.7.31 -34
1 row in set (0.01 sec)
Query InnoDB status
다음 쿼리에서 볼 수 있듯이 지난 47초간 계산된 초당 평균 횟수입니다. 즉, 각 쿼리 중에 매개변수가 동적으로 변경됩니다.

mysql> 엔진
innodb 상태 표시\G;

---

** 1. 행 ***************

---

유형: InnoDB
이름:
상태:

===============

2022-06-27 09:33:40 0x
7fa1c8a5f700 INNODB
모니터 출력

===============

지난
47초 동안 계산된 초당 평균

BACKGROUND THREAD
(백그라운드 스레드)

srv_master_thread loops
: 13285067 srv_active, 0
srv_shutdown, 1060666
6 srv_idle
srv_master_thread 로그
플러시 및 쓰기: 238917
33
#####위 쿼리에서 볼 수 있듯이 srv
master_thread 루프는
마스터 스레드 루프 수
이며
상태 (active,
shutdown, idle) 실행하는데,
active 개수의 증가는
데이터 변경과 관련이 있고 query 와는 관련이 없습니다
.

##### srv active 와 srv active 의 차이점을 보면 알 수 있습니다. srv_idle .active와 idle의 값을
비교하여 시스템의 전체 부하를 구하며, active의 값이 클수록 서비스가 더 바쁜 것입니다. #####srv_master_thread log는 마스터 스레드가 리두 로그(redo log)를 디스크에 쓰는 횟수입니다.

세마포어(세마포어
)

OS WAIT ARRAY INFO:
예약 횟수 57836
764 #####OS 대기 배열
정보: 예상 횟수(
InnoDB 할당 슬롯 할당량)
OS WAIT ARRAY INFO:
신호 횟수 269276481
#####OS 대기
배열 정보: 신호 횟수(스레드
배열을 통해 신호 주파수를 얻음)
RW 공유 회전 0,
라운드 171890114, OS
대기 34656067 ###
##RW 공유 잠금 수,
폴링 시간, 대기 시간
RW-excl 회전 0, 라운드
1245774156, OS 대기
18379769 ### ##
RW의 배타적 잠금 수,
폴링 시간, 대기 시간
RW-sx 회전 80621,
라운드 1707842, OS
대기 34552 #
####RW의 sx(의도 배타적
잠금) 수, 폴링
1890114.00
대기당 회전 라운드 수: 17
-shared,
1245774156.00 RW-
excl, 21.18 RW-sx ##
###Each spin rounds per
wait 표시: 각 운영
체제는 mutex
spinlock round를 기다립니다
...
위 문은 innodb 스토리지 엔진의 현재 작업에 대한 다양한 정보를 표시할 수 있습니다. 를 통해 MySQL의 현재 문제점을 확인할 수 있으며, MySQL이 이러한 모니터링 도구를 제공한다는 점만 알면 필요할 때 자세히 쿼리할 수 있습니다.

1. BACKGROUND THREAD(백그라운드 스레드)
2. 세마포어(세마포어)
3. 최근에 감지된 교착 상태
4. 업무
5. FILE I/O(문건 IO)
6. INSERT BUFFER AND ADAPTIVE HASH INDEX(버퍼 및 적응형 해시 인덱스 삽입)
7. 통나무
8. BUFFER POOL AND MEMORY(버퍼 풀 및 메모리)
9. 행 작업

7. EXPLAN 실행 계획

느린 쿼리 로그를 통해 어떤 SQL문이 느리게 실행되는지 알 수 있는데 왜 느린 걸까요? 느린 것은 어디에 있습니까?
MySQL은 실행 계획 쿼리 명령인 EXPLAIN을 제공합니다. 이 명령을 통해 SQL 실행 계획을 볼 수 있습니다.
EXPLAIN은 MySQL 5.6.3 이후 UPDATE, DELETE 및 INSERT 문에 대해서도 분석할 수 있지만 일반적으로 SELECT 쿼리에는 여전히 사용됩니다. .
SQL 최적화란 SQL 자체의 구문에는 문제가 없지만 동일한 목적을 달성하기 위해 더 나은 작성 방법이 있다는 것을 의미합니다. 예를 들어:

使用小表驱动大表；用join改写子查询；or改成union
连接查询中，尽量减少驱动表的扇出（记录数），访问被驱动表的成本要尽量低，尽量在被驱动表的连接列上建立索引，降低访问成本；被驱动表的连接列最好是该表的主键或者是唯一二级索引列，这样被驱动表的成本会降到更低
大偏移量的limit，先过滤再排序

마지막에 대한 간단한 예를 들어보겠습니다. 다음 두 명령문은 동일한 목적을 달성할 수 있지만 두 번째 명령문의 실행 효율성은 첫 번째 명령문보다 훨씬 높습니다(스토리지 엔진은 InnoDB를 사용합니다)
. 1. 큰 오프셋을 사용한 쿼리
mysql> SELECT * FROM user_innodb LIMIT 9000000,10;
빈 집합(8.18초)

– 2. ID를 먼저 필터링한 후(ID가 인덱스를 사용하므로) 제한
mysql> SELECT * FROM user_innodb WHERE id > 9000000 LIMIT 10;
빈 집합(0.02초)

인덱스 최적화
느린 쿼리에 적합한 인덱스를 생성하는 것은 매우 일반적이고 효과적인 방법이지만 인덱스가 효율적으로 사용될지는 또 다른 문제입니다.

4. 스토리지 엔진 및 테이블 구조 최적화

1. 스토리지 엔진 선택

일반적인 상황에서는 MySQL의 기본 스토리지 엔진인 InnoDB를 선택하지만, 데이터베이스 성능 요구 사항이 지속적으로 향상되는 경우 스토리지 엔진의 선택도 중요한 영향 요인이 됩니다.

쿼리 작업과 삽입 작업이 많은 비즈니스 테이블에는 MyISAM을 사용하고, 임시 테이블에는 Memory를 사용하고,
동시성이 크고 업데이트가 많은 비즈니스에는 InnoDB를 선택하고,
무엇을 선택해야 할지 모르면 기본값을 사용 하는 것이 좋습니다 .

2. 필드 최적화

필드 최적화의 최종 원칙은 데이터를 올바르게 저장할 수 있는 가장 작은 데이터 유형을 사용하는 것입니다.
정수 유형: 저장 유형에 따라 최대 저장 범위가 다르므로 자연스럽게 저장 공간을 차지합니다
. 문자 유형: 길이가 확실하지 않은 경우 필드의 경우 Choose varchar여야 하지만 varchar는 현재 필드가 차지하는 길이를 기록하기 위해 추가 공간이 필요하므로 필드 길이가 고정되어 있는 경우 char을 사용하면 메모리 공간이 많이 절약됩니다.
Non-null: Null이 아닌 필드를 NOT NULL로 설정하고 기본값을 제공하거나 NULL 대신 특수 값을 사용하도록 시도합니다.
외래 키, 트리거 및 보기 기능을 사용하지 마십시오.
이미지, 오디오, 비디오 저장: 수행하지 않음 대용량 파일 직접 저장, 대용량 파일 접근 주소
대용량 필드 분할 및 데이터 중복성

5. 비즈니스 최적화

1. 비즈니스 최적화는 더 이상 MySQL 튜닝의 수단이 아니지만 비즈니스 최적화는 매우 효과적으로 데이터베이스 액세스 부담을 줄일 수 있습니다. 이와 관련하여 전형적인 예는 Taobao 입니다. 1. 과거에는 Double 11 밤에 쇼핑이 시작되었습니다. 모델,
in 최근 몇 년 동안 Double 11 예매 전선이 점점 길어져 반달 이상 미리 시작하여 다양한 예금 빨간 봉투 모델이 끝없이 등장했습니다.이 방법을 예매 전환이라고합니다. 이는 고객의 서비스 요청을 분산시킬 수 있으며 Double Eleven의 이른 아침까지 기다리지 않고 일괄 주문할 수 있습니다. 2.
Alipay는 Double Eleven 기간 동안 은행 카드 결제 대신 Huabei 결제를 사용할 것을 강력히 권장합니다. 소프트웨어의 끈적거림을 개선하기 위한 것이지만 Yu'ebao가 실제로 사용하는 Alibaba의 내부 서버를 사용하면 액세스 속도가 빠른 반면, 은행 카드를 사용하려면 은행 인터페이스를 호출해야 하므로 이에 비해 훨씬 느립니다.