1. index를 만드세요.
https://dev.mysql.com/doc/refman/5.7/en/create-index.html
Prefixes must be specified for BLOB and TEXT column indexes. / TEXT는 길이를 지정해야만(!) 됨. tinytext는 text의 일종임
단순 CREATE INDEX 인덱스명 ON 테이블명 (컬럼명(길이) );
복합 CREATE INDEX 인덱스명 ON 테이블명 (컬럼명(길이), 컬럼명(길이), ... );
어느 컬럼을 앞에 쓰고 뒤에 쓸지 등은 통계와 쿼리의 형태를 모르기 때문에 못 알려드림.

"카테고리, 타겟, 태그는 enum 같은 정해진 몇개의 텍스트 "
- 정해진 몇개의 텍스트라면 varchar를 사용하시는 편이 검색이 빠르던 것으로 알고있습니다.

"
select *
from fr_hit
where
 hitter=2 and
 category="community" and
 tag="inbox" and
 target=744
"

이 부분을 한개당 0.3초라고 하신 것 같은데, mysql 입장에서는 조금 다릅니다.
1. hitter가 2인것을 모든 행에서 찾고,
2. category가 community인것을 (1)을 찾은 모든 행에서 찾고,
3. tag가 inbox인 것을 (2)를 찾은 모든 행에서 찾고,
4. target이 fr_test.id와 같은것을 (3)을 찾은 모든행에서 찾는

위와 같은 형태로 돌아갑니다.
데이터에 따라 튜닝 형태가 달라지겠지만,  기본적으로 검색할 때는 가장 검색자료가 적은 것 (이름, 나이, 주민등록번호 열이 있다면 주민등록번호, 이름, 나이 순으로 검색.)부터 넣어야 하고, 다른 테이블과의 비교가 필요없는 경우에는 on이 아닌 where 절에 넣어 검색하는게 맞습니다.

데이터를 가지고 테스트 해볼 수 없어서 이 정도밖에 말씀드리지 못할 것 같습니다.

2. 아주 특별한 이유(하나의 row가 엄청 긴 경우 같은)가 없다면 VARCHAR로 type을 변경하는 것을 고려하세요.
https://dev.mysql.com/doc/refman/5.7/en/blob.html

3. join 조건인지 where 조건인지 구별하세요.

-- test code
CREATE TABLE aaa (
 aa INT
 , bb INT
)
;

CREATE TABLE bbb (
 aa INT
 , bb INT
)
;

INSERT INTO aaa ( aa, bb ) VALUES( 1, 2 )
, (2, 4)
, (3, 6)
;

INSERT INTO bbb ( aa, bb ) VALUES( 1, 100 )
, (4, 400)
;
-- 아래의 쿼리에서 aaa.bb = 2를 20 으로 바꿔서도 테스트
SELECT *
FROM aaa
LEFT OUTER JOIN bbb
 ON aaa.aa = bbb.aa
WHERE aaa.bb = 2
;
SELECT *
FROM aaa
LEFT OUTER JOIN bbb
 ON aaa.aa = bbb.aa
 AND aaa.bb = 2
;

4. 쿼리가 느린 이유로 질문시에는 통계값(데이터의 분포)와 EXPLAIN한 결과를 주세요.
https://dev.mysql.com/doc/refman/5.7/en/using-explain.html

도움 될지 모르지만. 저는 join 할 태이블에서 데이터를 걸러와서 조인을 걸었어여. join 만 걸면 오래 걸리길래. 우선 필요한 데이터를 조회 해놓고 조회된 정보를 join 으로 걸었더니 튜닝이 되었거든요.

fr_test 엔 뭐가있는지 알려주셔야 할꺼 같습니다만.. fr_test를 기준으로 left join하는데 해당 데이터엔 뭐가있는지 없네요. ft_test는 따로 조건이없음으로 fullscan하게 되겠네요. 무엇보다.. 저런 테이블 정보도 정보지만 위에 골방꾼님이 이야기했듯 실행계획 결과도 알려주셔야 해요..

어디서부터 글을 시작해야 하나 싶은데요.
먼저... 현재 컴퓨터의 연산 성능에서 단일 테이블 60만건에서 0.3초가 걸린다는 것부터 설계든 쿼리든 뭔가 심각한 문제가 있다는 얘기입니다.
그리고 모든 설계와 코딩은 명칭 하나까지 논리적인 설명이 가능해야 합니다.

본문을 읽으면서 드는 궁금점과 하고 싶은 말이..
1. 테이블 설계에서 varchar(256) 이 아닌 tinitext 를 사용한 이유가 무엇인가요?
2. sql 에서 join 절에는 검색 조건이 아닌 두 테이블의 relation 설명이 들어가야 합니다.
3. sql의 join 절에서 사용하는 관계 설명용 필드는 PK와 FK 필드만으로도 충분해야 합니다.
만약 3의 조건을 벗어난다면 테이블간의 관계 설계를 제대로 했는지 검증이 필요합니다.
4. 검색 조건은 where 조건에만 들어가야 합니다.
5. order 절이 없이 Limit 가 있다는것은 다른 결과가 나올 수도 있다는 것을 의미합니다.

DB 크기 1GB 이하 레벨에선 인덱스니 뭐니 하는 기법을 쓰기보다..
기본에 충실한 설계만으로도 해결이 되야 한다고 생각하고 아직까지 그걸 벗어나는 경우도 없었습니다.