MySQL의 경우 프라이머리키와 인덱스는 중복으로 걸릴수 없어서 경고가 뜨게 되는데,
뭐 경고를 무시하고 설정은 할수 있지만, 이것때문에 검색효율이 떨어지는건 아닐까 하는 생각이.. ^^;

릴레이션 테이블인 만큼, 프라이머리키가 없이 세개를 따로따로 INDEX를 걸어주면 어떤지 한번 테스트를 해보시고 누가 속도를 측정해주셨으면 좋겠네요. 저는 별로 Row가 많지 않아서 테스트가 잘 안되네요.

각각 INDEX를 거는것보다 프라이머리키로 3개 필드를 묶어주는게 빠르다면 INDEX키로 걸려있는 owner 을 없애는건 어떤가요?

일단 화면 출력 설정에서 태그를 랜덤이 아닌 인기도 등으로 변경하면 부하가 줄어든다는;;;

제 의도는 안쓰는게 아니라 쓰되 효율적으로 갈수 있는 부분이 있지 않을까하는 부분이였습니다. ^^;
랜덤태그 매력있는 놈인데 안쓰기에는 아깝죠.

먼저 mysql프로세스에서 계속 물려 있던 쿼리는 다음과 같습니다. (태그 뿌려주는 쿼리죠)

SELECT `name` FROM `{$database['prefix']}Tags` t,
    `{$database['prefix']}TagRelations` r,
    `{$database['prefix']}Entries` e
    WHERE r.entry = e.id AND e.visibility > 0 AND t.id = r.tag AND r.owner = $owner
    GROUP BY r.tag
    ORDER BY RAND() $aux

위 쿼리에서 사용된 테이블의 레코드수를 보면
entries테이블에는 약 1990여개의 레코드
tagrelations테이블에는 약 3400여개의 레코드
tags테이블에는 약 2000여개의 레코드를 가지고 있는 상황입니다.
(문제가 되었던 블로그 외에 2개의 블로그를 더 운영중이지만 해당 레코드수가 적어서 그런것인지는 몰라도 나머지 블로그
는 해당 쿼리가 모두 정상 처리 되고 있었습니다.)

이상이 없다가 갑자기 발생한 일이라서 다른 원인이 있을수 있겠지만(다른 원인과 우연히 겹쳐서 발생한 일일수도 있고...) 쿼
리 수정후 문제가 없어졌기에 이렇게 글을 쓰게 됐습니다.

mysql에 발만 담근 정도라 어떠한 생각을 말씀드리는것도 어려운 상황이라 이부분에 있어 한번 체크를 해주시면 어떨까 합니다.