MySQL 데이터베이스 최적화 소개(그림 및 텍스트)

이 기사는 MySQL 데이터베이스 최적화에 대한 소개(그림 및 텍스트)를 제공합니다. 이는 특정 참고 가치가 있으므로 도움이 될 수 있습니다.

한편으로는 데이터베이스 최적화는 시스템의 병목 현상을 식별하고 MySQL 데이터베이스의 전반적인 성능을 향상시키는 반면, 사용자의 응답 속도를 향상시키는 동시에 비용도 절감하기 위해서는 합리적인 구조 설계와 매개변수 조정이 필요합니다. 시스템 리소스를 최대한 많이 제공합니다. (관련 권장사항: MySQL 튜토리얼)

1. 최적화 개요

2. 저자는 최적화를 두 가지 범주로 나눕니다. , 소프트 최적화 및 하드 최적화는 일반적으로 데이터베이스 운영을 포함하는 반면, 하드 최적화는 서버 하드웨어 및 매개변수 설정 운영을 포함합니다.

2.1.1 쿼리문 최적화

1. 또는 DESCRIBE(약어: DESC) 쿼리문의 실행 정보를 분석하는 명령입니다.

2. 예시:

DESC SELECT * FROM `user`

Display:

인덱스, 데이터 항목 수 등의 정보가 들어 있습니다. 쿼리 데이터가 표시됩니다.

2.1.2 하위 쿼리 최적화

MySQL에서는 하위 쿼리 대신 JOIN을 사용해 보세요. 하위 쿼리에는 중첩 쿼리가 필요하므로 임시 테이블을 생성하고 삭제하면 됩니다. 시스템 오버헤드가 크지만 조인 쿼리는 임시 테이블을 생성하지 않으므로 중첩된 하위 쿼리보다 효율성이 높습니다.

2.1.3 인덱스 사용

인덱스는 데이터베이스 속도를 향상시키는 가장 중요한 방법 중 하나입니다. 쿼리에 대해서는 작성자의 기사 "MySQL 데이터베이스 인덱스"를 참조하세요. 소개가 더 자세히 설명되어 있습니다. 인덱스 사용 시 세 가지 주요 주의 사항은 다음과 같습니다.

LIKE 키워드는 '%'로 시작하는 문자열과 일치하며 인덱스는

OR 키워드의 두 필드는 모두 색인화되어야 하며, 쿼리는 색인을 사용합니다.

1. 다중 열 색인을 사용하면 가장 왼쪽 일치를 충족해야 합니다.
2. 2.1.4 테이블 분해
3. 필드 중 일부 필드의 사용 빈도가 낮을 ​​경우 이를 분리하여 새 테이블을 구성해야 합니다.

2.1.5 중간 테이블

많은 수의 연결을 쿼리하는 테이블의 경우 중간 테이블을 생성하여 데이터 사용량을 줄일 수 있습니다.

2.1.6 중복성 증가 필드

는 중간 테이블을 생성하는 것과 유사합니다.

2.1.7 분석 테이블, 테이블 확인, 최적화 테이블

분석 테이블은 주로 테이블 내 키워드의 분포를 분석하고, 체크 테이블은 주로 테이블에 오류가 있는지 확인합니다. 테이블 최적화는 주로 삭제나 업데이트로 인한 테이블 공간 낭비를 없애기 위한 것입니다. ANALYZE TABLE 사용자와 같은 ANALYZE 키워드를 사용하십시오.

Msg_type: 상태, 정보, 메모, 경고, 오류를 포함한 정보 유형을 나타냅니다.

테이블 확인. CHECK TABLE 사용자 [옵션]

옵션과 같은 CHECK 키워드는 총 5개의 매개변수 값인 MyISAM에만 유효합니다.

QUICK: 행을 스캔하지 않고 잘못된 연결을 확인하지 않습니다.

FAST: 테이블만 확인합니다.

CHANGED: 마지막 확인 이후 변경된 테이블과 올바르게 닫히지 않은 테이블만 확인합니다.

MEDIUM: 행을 스캔하여 삭제된 연결이 유효한지 확인하고 계산합니다. 각 행의 키워드 체크섬

EXTENDED: 가장 포괄적인 검사, 각 행의 키워드에 대한 포괄적인 검색

테이블 최적화: OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;

LOCAL|과 같은 OPTIMIZE 키워드를 사용하세요. NO_WRITE_TO_BINLOG는 모두 로그에 쓰지 않음을 의미합니다. 최적화된 테이블은 VARCHAR, BLOB 및 TEXT에만 유효합니다. OPTIMIZE TABLE 문은 실행 중 파일 조각화를 제거할 수 있습니다.

2.2 하드 최적화

2.2.1 하드웨어 3종 세트

1. 멀티 코어 및 고주파 CPU 구성. 멀티 코어는 여러 스레드를 실행할 수 있습니다.

2. 메모리를 늘리면 캐시 용량이 늘어납니다. /O 시간 및 응답 속도 향상

3. 고속 디스크 구성 또는 디스크 분산: 고속 디스크는 I/O를 향상시키고, 분산 디스크는 병렬 작업의 효율성을 향상시킬 수 있습니다.

2.2.2. 데이터베이스 매개변수

데이터베이스 매개변수를 최적화하면 리소스 활용도가 향상되어 MySQL 서버 성능이 향상될 수 있습니다. MySQL 서비스의 구성 매개변수는 모두 my.cnf 또는 my.ini에 있으며 아래에는 몇 가지가 나열되어 있습니다. 매개변수.

key_buffer_size: 인덱스 버퍼 크기

table_cache: 동시에 오픈할 수 있는 테이블 수

query_cache_size 및 query_cache_type: 전자는 쿼리 버퍼 크기, 후자는 이전 매개변수의 전환, 0은 버퍼를 사용하지 않음을 의미, 1은 버퍼를 사용하지만 쿼리에서 사용할 수 있음을 의미합니다. SQL_NO_CACHE는 사용하지 않음을 의미합니다. 버퍼, 2는 쿼리에서 버퍼를 사용할 때만 버퍼, 즉 SQL_CACHE를 사용해야 함을 분명히 지적하고 있습니다.

sort_buffer_size: Sorting buffer

Portal:추가 매개변수

2.2.3 Sub -라이브러리 및 하위 테이블

데이터베이스 압력이 너무 높기 때문에 첫 번째 문제는 높은 데이터베이스 부하가 성능에 영향을 미치기 때문에 피크 기간에는 시스템 성능이 저하될 수 있다는 것입니다. 또 다른 문제는 과도한 압력으로 인해 데이터베이스가 충돌하는 경우 어떻게 해야 합니까? 따라서 이때 시스템을 데이터베이스와 테이블로 분할 + 읽기-쓰기 분리, 즉 데이터베이스를 여러 데이터베이스로 분할하여 여러 데이터베이스 서비스에 배포한 다음 쓰기 요청을 처리하는 기본 데이터베이스 역할을 해야 합니다. 그런 다음 각 마스터 라이브러리는 하나 이상의 슬레이브 라이브러리를 마운트하고 슬레이브 라이브러리는 읽기 요청을 처리합니다.

2.2.4 캐시 클러스터

사용자 수가 점점 많아지면 이때에도 머신을 계속 추가하면 됩니다. 예를 들어 시스템 수준에서 머신을 계속 추가하면 더 높은 동시 전송이 가능합니다. 요청. 그러다가 데이터베이스 수준의 쓰기 동시성이 높아지면 데이터베이스 서버가 확장되고, 서브 데이터베이스와 테이블 샤딩을 통해 머신도 확장된다. 확장되고 더 많은 슬레이브 데이터베이스가 추가될 예정입니다. 그러나 여기에는 큰 문제가 있습니다. 데이터베이스 자체는 실제로 높은 동시 요청을 처리하는 데 사용되지 않으므로 일반적으로 초당 단일 데이터베이스 시스템이 수행하는 동시성은 수천 대에 달하며 데이터베이스에서 사용되는 시스템은 상대적으로 높은 구성, 상대적으로 비싼 기계, 비용이 매우 높습니다. 단순히 기계를 계속 추가한다면 실제로는 잘못된 것입니다. 따라서 캐시는 일반적으로 높은 동시성 아키텍처에 포함됩니다. 캐시 시스템은 높은 동시성을 수행하도록 설계되었습니다. 따라서 단일 머신이 전달하는 동시성 양은 초당 수만, 심지어는 초당 수십만입니다. 높은 동시성 전달 용량은 데이터베이스 시스템보다 1~2배 더 높습니다. 따라서 시스템의 비즈니스 특성에 따라 쓰기가 덜 필요하고 읽기가 더 필요한 요청에 대해 캐시 클러스터를 완전히 도입할 수 있습니다. 특히, 데이터베이스에 쓸 때 데이터 복사본이 동시에 캐시 클러스터에 기록되고 캐시 클러스터는 대부분의 읽기 요청을 전달하는 데 사용됩니다. 이 경우 캐시 클러스터링을 통해 더 적은 수의 시스템 리소스를 사용하여 더 높은 동시성을 호스팅할 수 있습니다.

결론

완전하고 복잡한 높은 동시성 시스템 아키텍처에는 확실히 다양하고 복잡한 자체 개발 인프라 시스템이 포함됩니다. 모든 종류의 정교한 건축 디자인. 따라서 작은 기사는 기껏해야 다른 사람에게 영감을 주는 효과를 가질 수 있지만 데이터베이스 최적화 아이디어는 그게 전부입니다.

위 내용은 MySQL 데이터베이스 최적화 소개(그림 및 텍스트)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!