tenant_id를 사용하는 Mysql 복합 색인

Question

WHERE 및 ORDER BY 절에서 모두 사용할 수있는 129 개의 필드가있는 표가있는 다중 점유 응용 프로그램이 있습니다. 저는 5 일 동안 지금 최고의 색인 생성 전략을 찾으려고 노력했지만 많은 지식을 얻었지만 아직 몇 가지 질문이 있습니다. 난 항상 (모든 쿼리가 tenant_id습니까? 그 첫 번째 장소에서 tenant_id와 복합 인덱스해야 인덱스를 만들 때

는

1) =? 거기에 절)

2) 모든 열을 사용할 수 있기 때문에 WHERE WHERE 절과 order by 절 모두에서 모두 인덱스를 만들어야합니까? (인덱스가없는 컬럼으로 주문할 때 약 1,500,000 행의 임차인과 함께 실행하려면 6 초가 걸립니다.)

3) PK (tenant_id, ID)를 작성하지만 조인에 영향을주지는 않습니다 그 테이블에?

이 문제를 해결하는 방법에 대한 조언은 매우 감사하겠습니다.

====== 데이터베이스 엔진은 InnoDB에

=======입니다

구조 : 질문에 대한

ID bigint(20) auto_increment primary 
tenant_id int(11) 
created_by int(11) 
created_on Timestamp 
updated_by int(11) 
updated_on Timestamp 
owner_id int(11) 
first_name VARCHAR(60) 
last_name VARCHAR(60) 
. 
. 
. 
(some 120 other columns that are all searchable) 

Answer 1

하는 몇 개의 간단한 답변. 지금까지 당신이 indexes

컬럼에 인덱스를 생성 고려하여 혼동되어 볼 수있는 경우 비 -

Consideration 1 -

/(수 (열의 고유 항목 수) 열의 전체 항목) ~ = 1

즉, 특정 열의 DISTINCT 행 개수가 많습니다. 당신이 은 모든 열 index를 작성해서는 안 있도록, MySQL 서버에 대한 추가index 항상 만듭니다 오버 헤드를 만들기

. 한계 인덱스의 수에 또한 당신의 한 표는 tenant_id 모든 검색어에 존재하는 지금, 만약 당신이 index로 또는 composite key에 고려해야 =

테이블

당 64를 가질 수 있습니다,

는 단 -

Consideration 2 - tenant_id

,745에 SELECTs 이하 그 수가 UPDATEs 수있다

Consideration 3 - indexe은 data types으로 가능한 한 작아야합니다.당신 이는 varchar 64 인덱스

Point to Note 1
http://www.mysqlperformanceblog.com/2012/08/16/mysql-indexing-best-practices-webinar-questions-followup/

를 작성해서는 안 - 당신은 모든 열을 인덱스를 선언 할 경우에도, MySQL의 최적화는 여전히 쿼리 실행이 최선 계획을 고려하지 않을 수 있습니다. 그래서 항상 EXPLAIN을 사용하면 무슨 일이 벌어 지는지 알 수 있습니다. http://www.mysqlperformanceblog.com/2009/09/12/3-ways-mysql-uses-indexes/

Point to Note 2 - 당신은 cache 검색 쿼리 할 수 ​​있습니다, 그래서 같은 마지막

NOW() 같은 SELECT 쿼리에서 예상치 못한 문, 사용하지 않는 기억 - 약동학 (tenant_id, ID)를 만들기를해야하지 테이블의 조인에 영향을줍니다.
일반적인 질문에 대한 답을 얻을 수있는 멋진 링크 - http://www.percona.com/files/presentations/WEBINAR-MySQL-Indexing-Best-Practices.pdf