은 MySQL 조인에 도움이 필요합니다.

Question

Users table 
user_id 
pic_url 
name 

friends table 
auto_id 
userid 
friendid 
status 

actions table 
auto_id 
userid 
type 
subject 
body 
datetime 

친구가 업데이트 된 것을 보여주고 싶습니다. 블로그 게시물 일 수도 있고 상태 변경 일 수도 있지만 로그인 한 사용자의 친구 만 표시해야합니다.

내 사용자베이스가 너무 커서 성능이 필수적입니다. 더 좋은 방법이 있습니까? 제발 보여주세요

SELECT u.user_id, u.pic_url, u.name, a.auto_id, a.userid, a.type, a.subject, a.body, a.datetime 
FROM actions AS a 
LEFT JOIN users AS u ON u.auto_id=a.userid 
LEFT JOIN friends AS f ON f.userid=a.userid 
WHERE f.friendid=1 //1 would be my user ID 
AND f.status=active 

제 생각으로는 이것이 올바른 것은 아닙니다.

50,000 명의 사용자가 있고 내 사용자 ID가 1이고 20,000 명의 사용자가있는 친구라고하면 친구 인 사용자가 게시 한 작업 테이블의 모든 항목을 반환해야하며 포함 시키려면 수정해야합니다 나 자신의 행동

더 빠른 조회를 위해 일종의 해시 테이블을 사용하는 것에 대해 talki가 들었습니다. 어떤 도움

Answer 1

에 대한

덕분에 나는 같은 것이 여기에 가능할 것이라고 빠른 조회를 위해 해시 테이블의 일종을 사용하는 방법에 대한 를 겠소 어떤 사람들 들었어요?

이는 index을라고, 당신은 당신이 JOIN을 사용하여 (또는 >, >=, =, <=, < 같은 명시 적 제약 조건 또는 진술 목록 항목 만 일치하는 IN() 절을 일치)에 계획하고있는 각 열에 하나를 추가해야 . 이렇게하면 데이터베이스 서버가 모든 테이블 행을 통해 무차별 강제 검색을 수행하지 않고 올바른 인덱스 항목으로 바로 이동할 수 있습니다. 그것은 책의 색인과 정확히 같습니다. "Knuth"라는 이름이있는 책에서 페이지를 찾으려면 두 가지 방법이 있습니다. 책에 색인이있는 경우 색인을보고 이름이 있기를 바랍니다. 책에 색인이 없으면 모든 것을 직접 읽어야하며 훨씬 오래 걸릴 것입니다.

정렬/정렬 (또는 모든 종류의 상대적인 숫자/문자열 비교 수행)을 신경 쓰면 정렬 된 인덱스 여야합니다. 그렇지 않으면 많은 행이있는 테이블의 경우 더 빠르지 만 정렬 정보는 전달하지 않는 해시 테이블 인덱스가 될 수 있습니다. 이러한 유형의 세부 정보는 사용되는 데이터베이스 서버 소프트웨어 유형에 따라 구문과 옵션이 다를 수 있습니다. ** (아래 참고 참조)

기본 키에는 이미 자동 생성 된 색인이 있으므로 자신을 추가해야합니다. 또한 여러 개의 열 기본 키가있는 경우 (예 : (State, City, Zipcode) 그러면 주 키의 가장 왼쪽 부분 집합에 효과적으로 인덱스가 생깁니다. (State, City) 및 (State, City, Zipcode)에 대한 색인을 무료로 얻을 수 있지만 Zipcode 또는 City 또는 (City, Zipcode)에 가입하려는 경우에는 자신의 색인을 기본 키가 제공하는 것 외에도.

귀하의 경우,이 열에 인덱스가 있어야합니다 (필자는 이미 기본 키라고 가정하는 컬럼을 * 작성했습니다). 사용자 ID의 숫자 순서에 중요한 의미가 없으면 해시 테이블 색인에 적합한 후보가됩니다.

---

Users.user_id* 
Friends.user_id 
Friends.friend_id 
Friends.active 
Actions.user_id 

** MySQL을 들어, 당신이 ... 해시 테이블 인덱스에 대한 해시를 사용하거나 (정렬 된 인덱스) BTREE를 사용 말한다 CREATE INDEX statement에 절을 추가하는이 공간을 위해만큼 RTREEs를 무시 데이터. MySQL은 일반적인 저장소 엔진 인 InnoDB와 MyISAM에 HASH 인덱스를 허용하지 않는다. 고성능이 필요한 대용량 데이터 세트는 해시 인덱스가있는 메모리 내장 테이블에 데이터를 미러링해야 할 필요가 있습니다. 50,000 개의 행을 사용하면 걱정하지 않아도됩니다. BTREE의 검색 시간은 O (log n)이고 HASH는 O (1)이고 그다지 차이는 없습니다. BTREE는 매우 넓고 깊지 않도록 설계되었습니다. 검색 단계에서 하나의 추가 비교가 필요하면 행 수를 10 또는 100만큼 늘려야 할 수도 있습니다.