2013-04-15 2 views
1

나는 feedwordpress WordPress 플러그인을 사용하고 있습니다.이 SQL 쿼리를 최적화하는 방법에 대한 아이디어

이것은 내 서버에서 매우 무거운 쿼리를 사용하며 어떻게 향상시킬 수 있는지 잘 모르겠습니다. 벨로우 (Bellow)는 호스팅 회사에서 얻은 결과물입니다. 개선의 희망이 있습니까?

는 (문제와 더 구체적인되지 않는,하지만 난 방법을 잘 모르겠어요 죄송합니다 - 그것을 개선하기 위해 질문을 편집 할 수 주시기 바랍니다! - 감사합니다) 여기에

most memory usage likely comes from the MySQL service: 
Uptime: 3 hours 32 min 48 sec 

Threads: 4 Questions: 761936 Slow queries: 254 Opens: 610 Flush tables: 1 Open tables: 603 Queries per second avg: 59.675 

It is up 3 and a half hour and already had more than 250 slow queries, I will list the last few queries, and once you manage to optimize these I'm sure the memory usage will decrease as well: 
# [email protected]: rblogger_rblogr[rblogger_rblogr] @ localhost [] 
# Thread_id: 5737 Schema: rblogger_rblog Last_errno: 0 Killed: 0 
# Query_time: 11.448474 Lock_time: 0.000059 Rows_sent: 0 Rows_examined: 66004 Rows_affected: 0 Rows_read: 66004 
# Bytes_sent: 89 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 
# InnoDB_trx_id: 25335B6 
SET timestamp=1366020031; 
SELECT ID FROM wp_rb_posts WHERE to_ping <> '' AND post_status = 'publish'; 
# Time: 130415 5:01:01 
# [email protected]: rblogger_rblogr[rblogger_rblogr] @ localhost [] 
# Thread_id: 5785 Schema: rblogger_rblog Last_errno: 0 Killed: 0 
# Query_time: 4.344107 Lock_time: 0.000129 Rows_sent: 2219 Rows_examined: 13192 Rows_affected: 0 Rows_read: 13192 
# Bytes_sent: 23262206 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 
# InnoDB_trx_id: 25335D9 
SET timestamp=1366020061; 
SELECT wp_rb_posts.* FROM wp_rb_posts WHERE 1=1 AND (((wp_rb_posts.post_title LIKE '%git%') OR (wp_rb_posts.post_content LIKE '%git%'))) AND (wp_rb_posts.post_password = '') AND wp_rb_posts.post_type IN ('post', 'page', 'attachment') AND (wp_rb_posts.post_status = 'publish') ORDER BY wp_rb_posts.post_date DESC; 
# Time: 130415 6:03:28 
# [email protected]: rblogger_rblogr[rblogger_rblogr] @ localhost [] 
# Thread_id: 8619 Schema: rblogger_rblog Last_errno: 0 Killed: 0 
# Query_time: 7.299722 Lock_time: 0.000092 Rows_sent: 0 Rows_examined: 66005 Rows_affected: 0 Rows_read: 66005 
# Bytes_sent: 89 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 
# InnoDB_trx_id: 2534534 
SET timestamp=1366023808; 
SELECT ID FROM wp_rb_posts WHERE to_ping <> '' AND post_status = 'publish'; 
# [email protected]: rblogger_rblogr[rblogger_rblogr] @ localhost [] 
# Thread_id: 8620 Schema: rblogger_rblog Last_errno: 0 Killed: 0 
# Query_time: 9.666021 Lock_time: 0.000037 Rows_sent: 0 Rows_examined: 66005 Rows_affected: 0 Rows_read: 66005 
# Bytes_sent: 89 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 
# InnoDB_trx_id: 2534533 
SET timestamp=1366023808; 
SELECT ID FROM wp_rb_posts WHERE to_ping <> '' AND post_status = 'publish'; 
# Time: 130415 6:58:25 
# [email protected]: rblogger_rblogr[rblogger_rblogr] @ localhost [] 
# Thread_id: 11340 Schema: rblogger_rblog Last_errno: 0 Killed: 0 
# Query_time: 4.616263 Lock_time: 0.000067 Rows_sent: 10 Rows_examined: 6014 Rows_affected: 0 Rows_read: 6014 
# Bytes_sent: 189 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 
# InnoDB_trx_id: 253530A 
SET timestamp=1366027105; 
SELECT SQL_CALC_FOUND_ROWS wp_rb_posts.ID FROM wp_rb_posts WHERE 1=1 AND (wp_rb_posts.post_author = 56) AND wp_rb_posts.post_type = 'post' AND (wp_rb_posts.post_status = 'publish') ORDER BY wp_rb_posts.post_date DESC LIMIT 0, 10; 

은 결과입니다 SHOW CREATE TABLE wp_rb_posts을 위해 :

CREATE TABLE `wp_rb_posts` (
`ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT, 
`post_author` bigint(20) unsigned NOT NULL DEFAULT '0', 
`post_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
`post_date_gmt` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
`post_content` longtext NOT NULL, 
`post_title` text NOT NULL, 
`post_excerpt` text NOT NULL, 
`post_status` varchar(20) NOT NULL DEFAULT 'publish', 
`comment_status` varchar(20) NOT NULL DEFAULT 'open', 
`ping_status` varchar(20) NOT NULL DEFAULT 'open', 
`post_password` varchar(20) NOT NULL DEFAULT '', 
`post_name` varchar(200) NOT NULL DEFAULT '', 
`to_ping` text NOT NULL, 
`pinged` text NOT NULL, 
`post_modified` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
`post_modified_gmt` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
`post_content_filtered` longtext NOT NULL, 
`post_parent` bigint(20) unsigned NOT NULL DEFAULT '0', 
`guid` varchar(255) NOT NULL DEFAULT '', 
`menu_order` int(11) NOT NULL DEFAULT '0', 
`post_type` varchar(20) NOT NULL DEFAULT 'post', 
`post_mime_type` varchar(100) NOT NULL DEFAULT '', 
`comment_count` bigint(20) NOT NULL DEFAULT '0', 
PRIMARY KEY (`ID`), 
KEY `post_name` (`post_name`), 
KEY `type_status_date` (`post_type`,`post_status`,`post_date`,`ID`), 
KEY `post_parent` (`post_parent`), 
KEY `wp_rb_posts_guid_idx` (`guid`), 
KEY `post_author` (`post_author`), 
KEY `guid` (`guid`) 
) ENGINE=InnoDB AUTO_INCREMENT=69681 DEFAULT CHARSET=utf8 

다음 진단 실행했다 다음 FOL와

EXPLAIN SELECT SQL_CALC_FOUND_ROWS wp_rb_posts.ID 
FROM wp_rb_posts 
WHERE 1 =1 
AND (
wp_rb_posts.post_author =56 
) 
AND wp_rb_posts.post_type = 'post' 
AND (
wp_rb_posts.post_status = 'publish' 
) 
ORDER BY wp_rb_posts.post_date DESC 
LIMIT 0 , 10 

lowing 출력 :

id select_type table type possible_keys key key_len ref rows Extra 
1 SIMPLE wp_rb_posts ref type_status_date,post_author post_author 8 const 5624 Using where; Using filesort 
+2

** 테이블 및 인덱스 정의를 표시해야합니다. ** 느린 쿼리를 진단하려면 설명이나 의역이 아닌 전체 테이블 및 인덱스 정의가 필요합니다. 테이블이 잘못 정의 된 것일 수 있습니다. 색인이 올바르게 작성되지 않았을 수 있습니다. 어쩌면 그 칼럼에 당신이 생각한 색인이 없을 수도 있습니다. 테이블과 인덱스 정의를 보지 않고는 말할 수 없습니다. 'EXPLAIN'을하는 방법이나 실행 계획을 얻는 방법을 알고 있다면 그 결과를 질문에 넣으십시오. –

+0

안녕하세요 Andy - 실행 쿼리를 작성할 수 있습니까? 나는이 질문을 기꺼이 업데이트 할 것이다. –

+0

@TalGalili : 검색어에 'EXPLAIN'접두어 만 붙이면됩니다. 테이블 정의를 위해,'SHOW CREATE TABLE ... '을 사용하십시오. –

답변

1

당신이 즉, MySQL 서버, 진단하고 조정하는 데 도움이 리눅스에 대한 몇 가지 패키지가 있습니다

  • mysqltuner
  • innotop을은
  • 조정 프라이머
+0

감사합니다. 슬프게도 관리되는 VPS를 사용하고 있습니다. 따라서이 도구를 사용하여 확인할 수는 없습니다. –

2
SELECT wp_rb_posts.* FROM wp_rb_posts WHERE 1=1 AND (((wp_rb_posts.post_title LIKE '%git%') OR (wp_rb_posts.post_content LIKE '%git%'))) AND (wp_rb_posts.post_password = '') AND wp_rb_posts.post_type IN ('post', 'page', 'attachment') AND (wp_rb_posts.post_status = 'publish') ORDER BY wp_rb_posts.post_date DESC; 

하나는, 나는 sur 하나의 문제는 리터럴의 앞뒤에 사용되는 % 와일드 카드, 즉 Contains 문자열 연산입니다. 예를 들어, 훨씬 빠른 쿼리는 LIKE 'git %'- StartsWith 작업이 될 것입니다. 다른 쿼리의 경우 인덱스가 테이블에 정의되는 방법을 게시하는 것이 매우 중요합니다.

% git % 문제를 해결하기 위해 특정 상황에서 수행 할 작업의 예는 삽입/업데이트 작업에서 '자식 (git)'개체가 있는지 계산할 트리거를 만듭니다 (MSSQL에서 작업 함) 레코드의 제목과 내용 모두에 포함 된 문자열을 반환하고 비트 필드를 (true)로 표시합니다. 이렇게하면 테이블의 삽입/업데이트 작업 속도가 느려지지만 (한 번에 하나의 레코드 만 삽입하거나 업데이트 할 때 중요하지는 않지만) 검색 쿼리의 성능이 크게 향상됩니다.

+0

"git"은 데이터 모델의 의미있는 부분이라고 생각하지 않습니다.이 쿼리는 "git"에 대한 블로그 게시물 검색에 대한 응답으로 생각됩니다. –

+0

@ NevilleK - 당신이 옳다고 생각합니다. –

+0

네, 저도 요. :) 그러나 Contains 작업은 피해야한다고 저는 생각합니다. –

3

먼저, 지원 포럼에 this 스레드를보십시오. (내가 도와 주신 것을 보았습니다.) - 문제가있는 유일한 사람은 아니며,이 스레드에는 몇 가지 제안 사항이 있습니다.

두 번째로 성능 문제를 디버그하기 위해 원격으로 호스팅 된 데이터베이스로 작업하는 것은 끔찍한 게임입니다. 특히 이것이 실제 서버 인 경우 특히 그렇습니다. 자신의 온건함을 위해 실제로 작업하고 실험 할 수있는 시스템에서 시스템을 재생성하는 것이 좋습니다.

적어도 MySQL이 (이상적으로는 서버와 동일한 버전으로) 실행되고 실제 환경에서 데이터베이스를 복원해야합니다.

다음으로 천천히 실행되는 쿼리를 실행하고 진행중인 작업을 해결하십시오. 내가 말할 수있는 한 최악의 범죄자에게는 일치하는 색인이 없습니다.

SELECT ID FROM wp_rb_posts WHERE to_ping <> '' AND post_status = 'publish'; 

는 to_ping 가능성이 post_status (해당 열의 카디널리티 많은 도움이 너무 낮을 수 있음)에 복합 인덱스 혜택을 누릴 것입니다.

SELECT SQL_CALC_FOUND_ROWS wp_rb_posts.ID 
FROM wp_rb_posts 
WHERE 1 =1 
AND (
wp_rb_posts.post_author =56 
) 
AND wp_rb_posts.post_type = 'post' 
AND (
wp_rb_posts.post_status = 'publish' 
) 
ORDER BY wp_rb_posts.post_date DESC 
LIMIT 0 , 10 

는 너무 컬럼의 대부분에 걸쳐 낮은 카디널리티를 가지고처럼 보이는 -하지만 당신은 행의 많은, POST_DATE을 기준으로 상위 10 비싼 될 것입니다 선택이있는 경우; where 절의 모든 열에 대해 복합 색인을 post_date로 생각해보십시오.

SELECT wp_rb_posts.* 
FROM wp_rb_posts 
WHERE 1=1 
AND (
    (
     (wp_rb_posts.post_title LIKE '%git%') 
    OR 
     (wp_rb_posts.post_content LIKE '%git%') 
    ) 
    ) 
AND (wp_rb_posts.post_password = '') 
AND wp_rb_posts.post_type IN ('post', 'page', 'attachment') 
AND (wp_rb_posts.post_status = 'publish') 
ORDER BY wp_rb_posts.post_date DESC; 

은 불쾌합니다. 텍스트 검색은 실제로 프리 텍스트 검색을 사용해야합니다. 이는 대용량 데이터 세트의 경우 매우 느릴 수 있습니다. 이 쿼리를 수정할 수 없다면 수정할 수있는 방법을 모르는 경우 다른 열에 복합 키를 추가 할 수 있지만 현재 쿼리의 모든 텍스트를 검색하는 것처럼 보입니다.

로컬 컴퓨터에 색인을 생성하고 차이가 있는지 측정하여 이상이 없는지 확인하십시오 (예 : 실수로 고유 색인을 추가하는 등).

관련 문제