다음 쿼리는 실행하는 데 6.6 초가 걸렸고 26 개의 행을 생성했습니다.
EXPLAIN 결과는 키를 사용하여 23 행과 48 행을 스캔하는 'ref'유형의 두 개의 간단한 쿼리입니다.
테이블 f에는 1000 개의 행이 있고 테이블 m에는 42000 개의 행이 있습니다.
seltype 테이블 유형 키 key keylen 참조 행 필터링 추가
SIMPLE f ref PRIMARY, forum_site_id 4 const 23 100.00 Where 사용; 임시 사용; 파일
정렬 사용 forum_site_id,
forums_flag_list_new_posts
SIMPLE m ref forum_msg_forum_id, forum_msg_forum_id 5 locali_db.f.id 48 100.00 where
forum_msg_status,
forum_msg_date 사용
다음은 쿼리입니다 (아주 간단한 것입니다).
SELECT
m.id AS msg_id,
m.public_id AS msg_public_id,
more fileds of this table ...
f.id AS forum_id,
f.public_id AS forum_public_id,
more fileds of this table ...
FROM
forum_msgs m
INNER JOIN forums f ON
m.forum_id = f.id
WHERE
f.site_id = 19
AND f.flag_list_new_posts = 1
AND m.msg_date >= 1434803744
AND m.status <> 11
ORDER BY
m.msg_date DESC
LIMIT
100
WHERE 및 ORDER BY 절의 모든 필드는 INTEGER 유형이며 INDEX로 정의됩니다. forum_id 필드는 FOREIGN KEY로 정의됩니다.
터무니없는 성능의 원인이 무엇인지 알게되어 기쁩니다. :)
데이터베이스는 상당히 높은 QPS (최대 200 개)로 RDS에서 실행되었습니다. 평균적으로 디스크에 50 IOP / s가 발생했습니다. 인스턴스 스토리지 유형을 마그네틱에서 일반 SSD로 변경하면 문제가 해결되었습니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다