SELECT a.idx, a.send_mb_id, a.recv_mb_id,
      b.mb_nick AS send_mb_nick, b.mb_level AS send_mb_level,
      c.mb_nick AS recv_mb_nick, c.mb_level AS recv_mb_level
FROM {$this->tables->friends_table} a
INNER JOIN {$maindb_name}.g5_member b
    ON (a.send_mb_id = b.mb_id)
INNER JOIN {$maindb_name}.g5_member c
    ON (a.recv_mb_id = c.mb_id)
WHERE (a.send_mb_id = :mb_id OR a.recv_mb_id = :mb_id)
LIMIT 20

쿼리는 이렇게 작성 되어 있고, g5_member 테이블과 friends테이블 각 3천개정도의 데이터가 있습니다.
friends테이블에는 send_mb_id, recv_mb_id 각 필드에 인덱스를 줬고, EXPLAIN을 했을땐 possible_keys에 각 키가 잘 들어가 있습니다. friends 테이블 구조는 idx(primary key) 와 나머지 쿼리문 구조와 같습니다.

friends 테이블 구조가 쿼리에 쓰여진 컬럼처럼
a.idx, a.send_mb_id, a.recv_mb_id
3개의 컬럼만 존재한다는 건가요?
그렇다고 해도 인덱스 정보가 필요하고
구조를 제공하면 인덱스 정보도 포함되기 때문에
다시 질문하고 다시 답변하는 시간비용을 줄이고자 구조가 필요하다고 한 것입니다.

g5_member 테이블의 구조는
https://github.com/gnuboard/gnuboard5/blob/master/install/gnuboard5.sql
에서 확인할수 있습니다만

혹시나 커스텀이 되어 있다면 이것 역시 별도로 구조가 제공되어야 하고
friends 테이블도 확인할 방법이 없기 때문에 역시 구조가 제공되어야 합니다.

쿼리도 php 에서 사용되는 변수및 바인딩 구문이 섞인 상태인데
복잡성 여부를 떠나 완전하게 해석된 쿼리가 아니면 제3자는 그것을 유추해야 합니다.

friends 테이블의 구조가 제공되지 않았기 때문에 현재 상태에서는
쿼리에 사용된 a.send_mb_id, a.recv_mb_id 컬럼에 인덱스가 없어서 그런 현상이 발생하는건 아닐까 추측해봅니다.

추가로 완전하게 해석된 쿼리로 EXPLAIN 을 확인해 보는 방법도
자체적 문제해결에 도움이 되지 않을까 싶습니다.

아무런 변화가 없습니다..ㅜㅜ

인덱스도 재등록 해보시구요 ;;

{$this->tables->friends_table}
에 인덱스가 적당하지 않으면
이 테이블부터 드라이브 합니다

Show index from
FROM {$this->tables->friends_table}
Show index from g5_member
결과를 올려 보세요