더 나은 성능을 위해 SQL 쿼리를 프로파일링하는 방법

게시 됨: 2023-03-16

Servebolt에서 우리는성능에 살고 숨 쉬고 있습니다 .

데이터베이스 성능도 예외는 아닙니다.

웹 사이트 방문자가 링크를 클릭한 후 비효율적인 쿼리를 실행하면 사용자 경험이 크게 저하 됩니다 .느린 쿼리가 실행될 때까지 기다려야 하며 페이지 렌더링과 같은 다른 작업이 수행되기 전에 몇 초가 걸릴 수 있습니다. 이 대기 시간에는 쿼리를 실행하는 데 필요한 시간뿐 아니라 전처리 및 후처리에 필요한 추가 시간도 포함됩니다. 결과적으로 잘못 설계된 쿼리는 웹 사이트의 전반적인 성능을 크게 저하시켜 사용자 경험을 실망스럽게 만들 수 있습니다.

TTFB(Time to First Byte)는 사용자가 웹 사이트에 요청한 후 데이터의 첫 번째 바이트를 수신하는 데 걸리는 시간을 측정하는 방법입니다.또한 사이트를 평가할 때 검색 엔진에서 사용하는 주요 메트릭이기도 합니다. 느린 쿼리가 트리거되면 TTFB에 부정적인 영향을 미칩니다. 느린 쿼리를 실행하는 데 시간이 오래 걸릴수록 TTFB가 높아져 전체 웹 사이트 성능이 느려지고 사용자 경험이 덜 만족스러워집니다.

이 가이드에서는 데이터베이스 응답에 의존하는 웹 애플리케이션의 성능을 유지하는 데 중요한 부분인 SQL 쿼리를 프로파일링하는 방법을 안내합니다. 이것은 성능을 향상시키기 위해 이러한 쿼리를 최적화하는 작업을 시작할 수 있도록 토대를 설정하는 프로세스입니다.

SQL 쿼리 프로파일링 이해

웹 애플리케이션을 개발하고 더 큰 규모로 작동하기 시작하면 원활하게 실행되었던 SQL 쿼리가 성능 문제를 일으킬 수 있습니다. 일반적으로 초당 요청 수가 증가함에 따라 증가하는 데이터 양에 대해 실행되는 쿼리 수가 증가하는 경향이 있습니다. 그리고 성능이 저하되면 사이트, 소프트웨어 또는 서비스와 상호 작용할 때 사용자의 경험도 저하됩니다.

쿼리 프로파일링은 데이터베이스 쿼리를 분석하고 성능을 평가하며 잠재적인 문제를 식별하는 방법입니다.

이러한 문제가 있는 쿼리를 분석하고 식별함으로써 데이터베이스 성능에 측정 가능한 차이를 만들 수 있는 특정 개선 사항을 만들 수 있습니다. 그러면 앱과 사이트의 응답성이 향상되므로 향후 확장성이 향상되고 전반적인 고객 만족도가 향상될 것입니다.

MariaDB(및 MySQL)는 이 기사에서 다룰 쿼리 프로파일링을 위한 몇 가지 도구와 기술을 제공합니다. 느린 쿼리가 식별 되면 다음 단계는 쿼리를 최적화하는것입니다 . 이 프로세스에는 문제의 근본 원인을 식별하고 효율성을 개선하기 위해 쿼리 구조를 변경하는 작업이 포함됩니다.

SQL 쿼리를 프로파일링하는 방법(7가지 방법)

개선 노력을 어디에 집중해야 하는지 알 수 있도록 느리고 비효율적인 쿼리를 식별하는 데 사용할 수 있는 다양한 도구와 기술을 분석하여 시작하겠습니다.

1 – EXPLAIN EXTENDED명령

SQL 쿼리를 분석하는 데 사용할 수 있는 도구 중 하나는EXPLAIN 명령입니다.

쿼리에서 EXPLAIN 명령을 실행하면 사용되는 인덱스 및 검사되는 행 수를 포함하여 쿼리가 실행되는 방식을 볼 수 있습니다.

EXPLAIN SELECT * FROM orders

JOIN customers ON orders.customer_id = customers.customer_id

WHERE customers.name = 'John Smith';

쿼리에서 EXPLAIN명령을 실행하면 다음을 비롯한 여러 열이 포함된 결과 집합이 반환됩니다.

id: 실행 계획에서 쿼리의 고유 식별자
select_type: SIMPLE 또는 SUBQUERY와 같은 쿼리 유형
table: 쿼리되는 테이블
type: JOIN 또는 INDEX와 같은 사용된 조인 유형
possible_keys: MariaDB 또는 MySQL이 쿼리를 처리하는 데 사용할 수 있는 인덱스
key: MariaDB 또는 MySQL이 실제로 쿼리를 처리하는 데 사용한 인덱스
key_len: 사용된 키의 길이
rows: MariaDB 또는 MySQL이 쿼리에 대해 검사할 행 수를 추정합니다.

Extra: 풀 테이블 스캔 여부, 임시 테이블 사용 여부 등 쿼리에 대한 추가 정보를 포함한다.

EXPLAIN명령 의 출력을 분석하면 일반적으로 열악한 인덱싱, 최적이 아닌 조인 유형 또는 많은 수의 검사된 행과 같은 잠재적인 성능 병목 현상을 식별할 수 있습니다.

예를 들어 유형 열에 "index" 대신 "ALL"이 표시되면 쿼리가 전체 테이블 스캔을 수행하는 것이므로 거의 확실히 성능이 저하될 것입니다. 키 열이 NULL이면 MySQL이 인덱스를 사용하지 않는 것이므로 속도가 느려집니다. 행 열의 값이 높으면 많은 행을 검사하고 있음을 의미하므로 성능이 더 저하됩니다.

추가 정보를 제공하는 데 도움이 되도록 EXPLAIN EXTENDED 변형을 사용하는 것이 좋습니다 .

참고: MySQL에서는 더 이상 사용되지 않지만 MariaDB에서는 계속 사용할 수 있습니다.

EXTENDED 옵션을 사용하면 조사된 행 수, 반환된 행 수, 사용된 JOIN 유형에 대한 정보, 스캔된 테이블의 순서, 사용된 인덱스 및 기간과 같은 유용한 정보를 볼 수 있습니다. 쿼리가 실행되었습니다.

EXPLAIN EXTENDED 명령을 사용하는 방법은 다음과 같습니다.

EXPLAIN EXTENDED SELECT * FROM your_table WHERE column_name = 'value';

이 예에서 EXPLAIN 명령은 데이터베이스가 쿼리를 실행하기 위해 수행할 단계 목록과 사용할 리소스 목록을 표시합니다.

이 명령을 사용하면 쿼리에서 병목 현상을 더 쉽게 발견할 수 있으므로 필요한 변경을 수행할 수 있으므로 병목 현상을 완화하고 쿼리 성능을 높일 수 있습니다.

예를 들어 EXPLAIN EXTENDED 명령을 사용하면 인덱스 추가 필요성을 식별하고, JOIN 조건을 최적화하고, 쿼리에서 반환되는 총 행 수를 제한하는 데 도움이 될 수 있습니다.

또한 정확한 결과를 얻으려면 이 테스트 및 최적화를 수행할 때 쿼리 캐싱을 비활성화했는지 확인해야 합니다. 이렇게 하려면 클라이언트를 연결할 때 먼저 이 명령을 실행하십시오.

SET SESSION query_cache_type=0;

쿼리를 변경한 후에는 성능을 다시 테스트하여 얼마나 개선되었는지 확인합니다(있는 경우). 쿼리의 모든 프로파일링 및 최적화와 마찬가지로 프로세스는 반복적입니다. EXPLAIN EXTENDED 명령을 사용한 다음 성능 테스트를 여러 번 수행해야 합니다.

2 – EXPLAIN ANALYZE명령

이 명령은 쿼리의 실행 계획을 분석하고 쿼리를 실행하는 데 걸린 실제 시간 및 실제로 검사한 행 수와 같은 성능 메트릭을 반환하는 데 사용됩니다. EXPLAIN ANALYZE 명령의 결과를 분석하여 인덱스 부족 또는 검사해야 하는 많은 수의 행과 같은 쿼리 실행의 잠재적인 병목 현상을 식별할 수 있습니다.

3 – 느린 쿼리 로그

이것은 실행하는 데 일정 시간보다 오래 걸리는 모든 쿼리를 기록하는 MariaDB(및 MySQL)의 기본 제공 기능입니다. 느린 쿼리 로그는 특정 임계값(예: 1초)보다 오래 걸리는 쿼리를 기록하도록 구성할 수 있습니다.

Servebolt에서 느린 쿼리 로그는 실행하는 데 1초 이상 걸리는 모든 쿼리를 기록합니다. 이는 대부분의 쿼리가 1초 이내에 실행되어야 하기 때문입니다. WordPress를 실행하는 사이트와 같은 웹 애플리케이션의 맥락에서 단일 페이지를 로드하려면 10~100개의 데이터베이스 쿼리가 필요하며 페이지가 HTML로 컴파일되어 사용자에게 반환되기 전에 모두 순차적으로 실행되어야 합니다.

현재 Servebolt Cloud 구성은 글로벌 로그 서버에 느린 쿼리 로그를 유지합니다. 필요한 경우 지원 팀에 연락하면 관련 로그에 대한 파일을 필터링하고 출력을 제공합니다.

자체 환경에서 MariaDB 또는 MySQL 구성 파일(my.cnf 또는 my.ini)에 다음 줄을 추가하여 느린 쿼리 로그를 활성화할 수 있습니다.

log_slow_queries = /path/to/slow.log

long_query_time = 1

4 – 시각적 설명 계획

시각적 Explain Plan은 EXPLAIN 명령 출력을 그래픽으로 표시 하여 쿼리 실행을 쉽게 이해하고 성능 문제를 감지할 수 있도록 합니다.

참고: Visual Explain Plan은 웹 애플리케이션 개발 프로세스에 있을 때 유용합니다.

일반 텍스트 출력 대신 쿼리 실행을 트리 구조 로 표시합니다 . 각 노드는 테이블, 인덱스 또는 작업을 나타내며 이들 간의 연결은 작업 순서를 나타냅니다.

MySQL Workbench 및 EXPLAIN Analyzer와 같은 다양한 도구는 시각적 설명 계획을 생성하고 실행 계획을 탐색하고 각 작업을 자세히 검사하기 위한 대화형 인터페이스를 제공할 수 있습니다.

예를 들어, MySQL Workbench에서 시각적 설명 계획을 생성하는 것은 쿼리를 실행하고 결과 탭에서 "계획 설명 " 버튼을 클릭하는 것만큼 간단합니다.이는 각 작업에 대한 자세한 정보와 함께 쿼리 실행 계획을 그래픽으로 표시합니다. 이를 통해 성능 문제를 식별한 다음 필요에 따라 쿼리를 최적화할 수 있습니다.

5 – MySQL 튜너

MySQL Tuner는 데이터베이스 서버의 성능 및 구성을 확인하고 개선을 위한 권장 사항을 제공하는 스크립트입니다. 총 쿼리 수, 느린 쿼리 수 및 현재 버퍼 풀 사용량과 같은 정보를 포함하여 현재 서버 상태에 대한 요약을 제공합니다.

또한 데이터베이스 버전, 사용 중인 스토리지 엔진 및 쿼리 캐시 구성과 같은 다양한 기타 설정을 확인하는 데 사용할 수 있으며 현재 워크로드를 기반으로 이러한 설정을 최적화하기 위한 권장 사항을 제공합니다.

다른 도구와의 주요 차이점 중 하나는 서버 자체에서 또는 원격으로 실행할 수 있는 명령줄 도구이므로 데이터베이스 성능 모니터링 및 최적화 프로세스를 쉽게 자동화할 수 있다는 것입니다.

참고: 웹 애플리케이션(및 데이터베이스)이 이미 Servebolt Cloud에서 호스팅되는 경우 – 이것은 우리 팀이 전문화하고 도구가 제공할 수 있는 어떤 권장 사항보다 더 잘 할 수 있습니다.

6 – 쿼리 프로파일러

MariaDB Enterprise Query Analyzer , Dataedo 및 Percona Toolkit 과 같은 SQL 쿼리를 프로파일링하는 데 사용할 수 있는 타사 쿼리 프로파일러가 있습니다 . 타사 쿼리 프로파일러는 MariaDB(또는 MySQL)에서 사용할 수 있는 기본 제공 도구와 비교하여 추가 기능을 제공할 수 있습니다.

참고: 쿼리 프로필러는 웹 응용 프로그램을 개발하는 과정에 있을 때 유용합니다.

예를 들어 실행 시간 및 잠금 대기 시간과 같은 쿼리 성능에 대한 자세한 정보를 제공할 수 있으며 기본 제공 도구로는 불가능한 방식으로 데이터 시각화를 제공할 수 있습니다.

기본 제공 도구가 필요에 따라 충분하다면 타사 쿼리 프로파일러를 사용할 필요가 없습니다. 그러나 더 자세한 정보나 고급 기능이 필요한 경우 타사 프로파일러를 고려해 볼 수 있습니다.

7 – 모니터링 도구를 사용한 프로파일링

Prometheus, Grafana 및 Nagios와 같은 여러 모니터링 도구도 쿼리를 프로파일링하고 데이터베이스 성능을 모니터링하는 데 사용할 수 있습니다.

Prometheus 는 메트릭 데이터를 수집, 저장 및 쿼리할 수 있는 효율적인 모니터링 시스템으로 귀중한 통찰력을 실시간으로 얻을 수 있습니다.MariaDB(및 MySQL)와 통합되어 수집된 메트릭을 저장하고 효과적인 시각화를 위해 Grafana와 함께 제공됩니다.

Grafana 는 Prometheus에서 수집한 데이터를 모니터링하고 시각화하는 데 사용할 수 있는 강력한 오픈 소스 분석 도구입니다.맞춤형 대시보드 및 경고를 설정하면 데이터베이스 성능을 실시간으로 주시할 수 있습니다.

Nagios는 데이터베이스의 상태를 항상 주시할 수 있도록 도와줍니다.CPU, RAM 및 디스크 공간과 같은 주요 리소스를 모니터링하는 동시에 다른 서비스 및 네트워크 장치를 추적하도록 설정할 수 있습니다. 고도로 구성 가능하므로 능동적인 데이터베이스 쿼리 모니터링을 위한 훌륭한 도구입니다.

이러한 서버 모니터링 도구를 사용하면 성능 문제를 추적하고 신속하게 조치를 취할 수 있으므로 데이터베이스 서버가 원활하게 실행되도록 할 수 있습니다.

일반적인 쿼리 최적화 기술

SQL 쿼리의 성능을 향상시키는 데 사용할 수 있는 몇 가지 일반적인 쿼리 최적화 기술이 있습니다.

1 - 인덱싱

인덱스는 특히 필터(WHERE)를 사용하는 쿼리의 속도를 높이는 방법입니다.인덱스를 사용하면 특정 테이블 외부의 데이터베이스 엔진(MariaDB 또는 MySQL)에서 데이터 구조가 생성되고 쿼리하려는 데이터를 가리킵니다. 인덱스를 사용하여 데이터베이스 쿼리를 개선하는 것은 자체 문서를 보장하므로 이 게시물에서는 너무 자세하게 다루지 않을 것입니다. 이는 향후 다룰 예정입니다.

예를 들어 주문 ID, 고객 ID 및 주문 날짜와 같은 정보를 포함하여 수백만 개의 데이터 행이 포함된 "주문"이라는 대형 테이블을 생각해 보십시오. 쿼리가 실행되어 고객 ID 열에 대한 인덱스 없이 특정 고객이 주문한 모든 주문을 검색하는 경우 MariaDB는 관련 데이터를 찾기 위해 전체 테이블을 스캔해야 합니다. 특히 큰 테이블의 경우 상당한 시간과 리소스가 필요할 수 있습니다.

대체로 특정 쿼리를 반복적으로 실행하고 성능 문제를 읽을 것이라고 확신할 때마다 인덱스(또는 둘 이상)를 만드는 것이 해당 쿼리 속도를 높이는 올바른 접근 방식이 될 수 있습니다.

WordPress의 맥락에서 이것은 매우 일반적입니다. 많은 플러그인은 (편의상) 인덱스를 사용하지 않고 일반 공유 테이블을 사용하는 개발자에 의해 구축됩니다. 그 결과 종종 상당한 성능 향상이 있는 영역이기도 합니다.

특정 테이블에 있는 인덱스를 보려면

wp_postmeta 테이블 에 대한 아래 예와 같이 SHOW INDEX FROM을사용하여 특정 테이블에 존재하는 인덱스를 볼 수 있습니다 .

MariaDB [db_name] > SHOW INDEX FROM wp_postmeta;

한 시나리오에서 최근에 wp_postmeta 테이블에 대해sb_postid_metakey 및 sb_postid_metakey_metaval이라는 두 개의 인덱스를 만들었습니다 .

이러한 인덱스는 상위 느린 쿼리를 살펴보고 많은 (AND/OR) 비교 조건 외에도 WHERE를 사용하여 필터링하는 SELECT 문이라는 특성으로 인해 모두 상대적으로 유사하다는 사실을 기반으로 추가되었습니다. 이것을 보고 사용된 테이블의 현재 인덱스를 검토하고 내 접근 방식을 추가로 검증하기 위해 쿼리에서EXPLAIN EXTENDED를 실행했습니다.

쿼리는 대부분 작동하고JOIN을사용하여 wp_postmeta 테이블을 사용했습니다 .이것이 발생한 순서에 따라 이러한 인덱스를 추가하면 MariaDB(또는 MySQL)가 모든 행이 있는 전체 테이블을 스캔하는 대신 인덱스에서 응답을 얻을 수 있습니다.

CREATE INDEX sb_postid_metakey ON wp_postmeta (post_id, meta_key);

CREATE INDEX sb_postid_metakey_metaval ON wp_postmeta (post_id, meta_key, meta_value);

이것은 (위에서 설명한 대로) 마음대로 사용할 수 있는 도구와 데이터베이스의 데이터 유형 및 내용에 대한 지식을 사용하여 "문제를 파악"하는 것의 조합입니다. 이것이 항상 작동하는 것은 아닙니다. 그렇더라도 성능이 항상 500% 향상되는 것은 아닙니다. 거대한 인덱스를 사용하면 모든 행을 스캔하는 것보다 속도가 느려질 수 있으므로 확실히 하려면 인덱스를 적용하기 전과 후에 쿼리를 테스트해야 합니다.

참고: 인덱스 속도를 테스트할 때 다음을 사용하여 세션에 대한 쿼리 캐싱을 비활성화할 수 있습니다.

SET SESSION query_cache_type=0;

이 경우 인덱스를 사용하기 전에 쿼리를 실행하는 데 10.437초가 걸렸습니다. 그리고 두 개의 인덱스를 생성한 후 동일한 쿼리에 [# of 초]가 걸렸습니다.

2 – 데이터 액세스 줄이기

데이터 액세스 감소 , 즉 쿼리를 실행하기 위해 액세스해야 하는 행과 열의 수를 최소화합니다.이는 쿼리로 검색된 데이터를 필터링하고, 인덱스를 사용하고, 큰 테이블을 분할하여 달성할 수 있습니다. 대부분의 사람들이 해야 하는(또는 할 수 있는) 것은 아니지만 처음부터 데이터베이스 쿼리를 설계할 때 염두에 두어야 할 필수 사항입니다.

예를 들어, 데이터베이스 쿼리가 로그인 목적으로 사용자에 대한 데이터를 조회하는 경우 쿼리는 LIMIT 1이어야 합니다. 분명히 두 명 이상의 사용자 데이터가 필요하지 않기 때문입니다.

참고: 이것은 최적화보다 데이터베이스 디자인과 더 관련이 있습니다.성능을 유지하는 것이 중요하지만 이러한 노력은 대부분의 최종 사용자보다 플러그인 개발자(WordPress 맥락에서)와 더 관련이 있습니다.

데이터 액세스를 변경한 후 속도를 테스트하기 전에 다음 명령을 실행하여 쿼리 캐싱을 비활성화했는지 확인해야 합니다.

SET SESSION query_cache_type=0;

3 – 데이터 분할 사용

데이터를 더 작은 청크로 파티셔닝하면 데이터베이스의 효율성이 높아지고 관리 시간이 줄어듭니다. 이 전략은 백업 및 업데이트와 같은 유지 관리 프로세스에 소요되는 시간을 줄이고 관리해야 하는 데이터의 양을 제한하는 데 도움이 될 수 있습니다. 전반적으로 성능을 개선하고 리소스 사용을 최적화하는 데 도움이 됩니다.

데이터베이스에서 데이터를 분할하려면 다음 단계를 따르십시오.

분할할 테이블을 선택할 때 많은 양의 데이터를 보유하고 분할의 이점이 있는 테이블을 선택해야 합니다. 이것은 시스템을 최적화하고 쿼리 성능을 향상시키는 데 도움이 됩니다.
데이터베이스에 적합한 파티셔닝 방법을 선택하는 것이 중요합니다. 데이터 구조 및 실행하려는 쿼리에 따라 범위, 목록, 해시 또는 키 분할 중에서 선택할 수 있습니다. 최적화된 성능과 결과에 대한 요구 사항에 가장 적합한 것을 선택했는지 확인하십시오.
1. 범위 분할은 특정 범위로 나눌 수 있는 데이터가 있는 경우 이상적인 선택입니다.예를 들어, 여러 해 동안의 데이터가 포함된 테이블이 있는 경우 범위 파티션을 생성하여 더 잘 구성할 수 있습니다. 해당 열의 날짜 또는 숫자 값을 기반으로 할 수 있습니다.
2. 목록 분할은 특정 매개 변수에 따라 다양한 그룹으로 쉽게 분리할 수 있는 데이터를 처리하는 효율적인 기술입니다.예를 들어 직원 정보가 부서별로 분류된 테이블이 있습니다. 이를 위해서는 목록 분할을 사용해야 합니다.
3. 해시 분할은 특정 열의 해시 값을 기반으로 동일한 크기의 클러스터로 데이터를 배열하는 효과적인 전략입니다.이를 통해 여러 파티션에 데이터를 고르게 분산할 수 있으므로 데이터를 효율적으로 분산하는 데 적합합니다.
4. 키 파티셔닝 은 해시 파티셔닝과 유사하지만 데이터를 여러 그룹으로 나누는 기준으로 특정 열 값을 사용한다는 점이 가장 큰 차이점입니다.따라서 고유 식별자 또는 자연 키를 기반으로 별도의 그룹으로 나눌 수 있는 데이터 세트에 이상적인 선택입니다.
분할된 테이블을 생성하면 원래 테이블을 더 작은 테이블로 효과적으로 나눌 수 있습니다. 이것은 분할을 위해 원하는 방법과 조건을 지정하는 CREATE TABLE 문에 분할 절을 추가하여 달성됩니다. 이렇게 하면 쿼리 성능을 개선하고 데이터 관리를 보다 효율적으로 수행할 수 있습니다.
INSERT INTO… SELECT 문을 사용하여 원본 테이블에서 새로 분할된 테이블로 데이터를 빠르게 복사할 수 있습니다. 이렇게 하면 분할된 테이블이 모든 관련 정보로 쉽게 채워집니다.
이제 분할된 테이블을 활용하도록 응용 프로그램을 재구성해야 합니다. 이렇게 하면 원래 테이블이 대체되고 응용 프로그램이 더 효율적으로 만들어집니다.
잠재적인 성능 향상을 평가하기 위해 테스트를 실행하기 전에 먼저 다음 명령을 실행하여 쿼리 캐싱을 비활성화해야 합니다. SET SESSION query_cache_type=0;
분할된 테이블이 원활하게 실행되도록 하려면 성능을 면밀히 주시하는 것이 중요합니다. 문제가 발견되면 파티셔닝 조건을 조정하거나 다른 방법으로 전환하는 것이 도움이 될 수 있습니다. 파티션을 정기적으로 모니터링하면 잠재력을 극대화하는 데 도움이 됩니다.

스크립팅 업그레이드 및 분할된 테이블에 대한 중요 참고 사항

데이터베이스 파티셔닝은 효율성 면에서 긍정적인 차이를 만들 수 있지만 업그레이드 스크립트를 실행하여 데이터베이스 스키마를 변경함으로써 발생할 수 있는 잠재적인 문제를 염두에 두는 것이 중요합니다. 이러한 업그레이드를 스크립팅할 때 분할된 테이블을 고려해야 합니다. 분할된 테이블이 업그레이드 스크립트에서 고려되지 않은 경우 오작동하는 사이트가 거의 확실하게 발생하는 잠재적인 문제가 있을 수 있습니다.

예를 들어 분할된 테이블에 새 열을 추가하기 위해 스크립트를 만든 경우 하나의 분할만 변경하여 데이터 내에서 불일치와 문제를 일으킬 수 있습니다. 마찬가지로 파티션된 테이블에 인덱스를 추가하기 위해 업그레이드 스크립트를 생성하는 경우 하나의 파티션에서만 인덱스를 생성할 수 있으므로 성능이 느려지고 결과가 일관되지 않습니다.

이러한 문제를 방지하려면 분할된 테이블을 고려하여 업그레이드 스크립트를 설계해야 합니다. 여기에는 각 분할 영역에서 개별적으로 스크립트를 실행하거나 분할된 테이블에서 작동하도록 스크립트를 수정하는 작업이 포함될 수 있습니다. 업그레이드 프로세스에서 예기치 않은 문제나 데이터 손실이 발생하지 않도록 철저한 테스트를 수행하는 것도 중요합니다.

4 - 레디스

Servebolt 고객의 경우 Redis는 쿼리 최적화에 도움이 되는 (유료) 애드온입니다.

Redis(원격 사전 서버라고도 함)는 데이터를 메모리에 저장하고 캐싱, 데이터베이스 또는 메시지 브로커로도 사용할 수 있는 오픈 소스 솔루션입니다. 성능을 향상시키기 위해 데이터베이스와 통합할 수 있으며 애플리케이션과 데이터베이스 간의 효율적인 중개자 역할을 합니다.

데이터베이스의 부하를 줄여 애플리케이션의 성능과 응답 시간을 개선합니다. 이는 모든 요청에 대해 데이터베이스가 아닌 Redis에 자주 사용되는 데이터를 저장하여 상당한 시간을 절약함으로써 이루어집니다.

플러그인을 올바르게 구성하면 Redis를 데이터베이스와 함께 사용하여 쿼리 실행을 최적화할 수 있습니다. 필요한 데이터가 Redis에 없으면 애플리케이션은 데이터베이스에서 검색하여 나중에 사용할 수 있도록 Redis에 저장합니다. 따라서 데이터 검색이 훨씬 빠르고 효율적입니다.

이 접근 방식을 사용하여 애플리케이션은 Redis의 빠른 메모리 내 액세스를 활용하고 필요에 따라 데이터베이스의 데이터를 저장 및 액세스할 수 있습니다.

Redis를 처음 구현하는 경우 성능 테스트를 실행하기 전에 쿼리 캐싱을 비활성화해야 합니다. 이렇게 하려면 다음 명령을 사용하십시오.

SET SESSION query_cache_type=0;

결론

MariaDB 및 MySQL 에코시스템에는 데이터베이스 쿼리 실행의 병목 현상을 쉽게 발견할 수 있는 다양한 도구와 방법이 있어 웹 애플리케이션의 성능을 향상할 수 있습니다.

응용 프로그램을 실행하는 동안 속도 저하가 발생할 수 있습니다. 이를 피하려고 노력하는 것은 좋지만 궁극적으로 성능 문제 진단을 시작할 때 어디를 살펴봐야 하는지 알아야 합니다. 실행하는 데이터베이스의 크기와 특성에 따라 데이터베이스 성능을 높은 수준으로 유지하기 위해 지속적인 모니터링, 문제 해결 및 지속적인 개선이 필요한 반복 프로세스입니다.