복합 인덱스가 MySQL에서 사용되지 않음

Question

MySQL 문서에 따르면 가장 왼쪽 필드가 조건의 일부인 경우 복합 인덱스가 계속 사용됩니다. 그러나이 테이블은 기본 키와 올바르게 결합하지 않습니다. 그 다음에 사용되는 왼쪽 두 필드의 다른 색인을 추가해야했습니다.

테이블 중 하나는 메모리이며 기본적으로 메모리는 그룹/주문에 사용할 수없는 해시 인덱스를 사용한다는 것을 알고 있습니다. 그러나 나는 메모리 테이블의 모든 행과 색인을 사용하지 않으므로 문제와 관련이 있다고 생각하지 않습니다.

무엇이 누락 되었습니까?

mysql> show create table pr_temp; 
| pr_temp | CREATE TEMPORARY TABLE `pr_temp` (
`player_id` int(10) unsigned NOT NULL, 
`insert_date` date NOT NULL, 
[...] 
PRIMARY KEY (`player_id`,`insert_date`) USING BTREE, 
KEY `insert_date` (`insert_date`) 
) ENGINE=MEMORY DEFAULT CHARSET=utf8 | 

mysql> show create table player_game_record; 
| player_tank_record | CREATE TABLE `player_game_record` (
`player_id` int(10) unsigned NOT NULL, 
`game_id` smallint(5) unsigned NOT NULL, 
`insert_date` date NOT NULL, 
[...] 
PRIMARY KEY (`player_id`,`insert_date`,`game_id`), 
KEY `insert_date` (`insert_date`), 
KEY `player_date` (`player_id`,`insert_date`) 
) ENGINE=MyISAM DEFAULT CHARSET=utf8 DATA DIRECTORY='...' INDEX DIRECTORY='...' | 

mysql> explain select pgr.* from player_game_record pgr inner join pr_temp on pgr.player_id = pr_temp.player_id and pgr.insert_date = pr_temp.date_prev;      
+----+-------------+---------+------+---------------------------------+-------------+---------+-------------------------------------------------------------------------+--------+-------+ 
| id | select_type | table | type | possible_keys     | key   | key_len | ref                  | rows  | Extra | 
+----+-------------+---------+------+---------------------------------+-------------+---------+-------------------------------------------------------------------------+--------+-------+ 
| 1 | SIMPLE  | pr_temp | ALL | PRIMARY       | NULL  | NULL | NULL                 | 174683 |  | 
| 1 | SIMPLE  | pgr  | ref | PRIMARY,insert_date,player_date | player_date | 7  | test_gamedb.pr_temp.player_id,test_gamedb.pr_temp.date_prev |  21 |  | 
+----+-------------+---------+------+---------------------------------+-------------+---------+-------------------------------------------------------------------------+--------+-------+ 
2 rows in set (0.00 sec) 

mysql> explain select pgr.* from player_game_record pgr force index (primary) inner join pr_temp on pgr.player_id = pr_temp.player_id and pgr.insert_date = pr_temp.date_prev; 
+----+-------------+---------+------+---------------+---------+---------+-------------------------------------------------------------------------+---------+-------+ 
| id | select_type | table | type | possible_keys | key  | key_len | ref                  | rows | Extra | 
+----+-------------+---------+------+---------------+---------+---------+-------------------------------------------------------------------------+---------+-------+ 
| 1 | SIMPLE  | pr_temp | ALL | PRIMARY  | NULL | NULL | NULL                 | 174683 |  | 
| 1 | SIMPLE  | pgr  | ref | PRIMARY  | PRIMARY | 7  | test_gamedb.pr_temp.player_id,test_gamedb.pr_temp.date_prev | 2873031 |  | 
+----+-------------+---------+------+---------------+---------+---------+-------------------------------------------------------------------------+---------+-------+ 
2 rows in set (0.00 sec) 

두 개의 왼쪽 열 (player_id, insert_date)이 사용되는 기본 키가 작동해야한다고 생각합니다. 그러나 기본적으로 player_date 인덱스를 사용합니다. 기본 인덱스를 사용하도록 강제하는 경우 두 인덱스가 아닌 한 필드 만 사용하는 것처럼 보입니다.

갱신 2 : MySQL의 버전 5.5.27 - 로그 갱신 3 : 는

mysql> show indexes in player_game_record; 
+--------------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| Table    | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | 
+--------------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| player_game_record |   0 | PRIMARY  |   1 | player_id | A   |  NULL |  NULL | NULL |  | BTREE  |   |    | 
| player_game_record |   0 | PRIMARY  |   2 | insert_date | A   |  NULL |  NULL | NULL |  | BTREE  |   |    | 
| player_game_record |   0 | PRIMARY  |   3 | game_id  | A   | 576276246 |  NULL | NULL |  | BTREE  |   |    | 
| player_game_record |   1 | insert_date |   1 | insert_date | A   |  33304 |  NULL | NULL |  | BTREE  |   |    | 
+--------------------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
4 rows in set (1.08 sec) 


mysql> select count(*) from player_game_record; 
+-----------+ 
| count(*) | 
+-----------+ 
| 576276246 | 
+-----------+ 
1 row in set (0.00 sec) 

Answer 1

가 동의 (이것은 다른 테스트를 시도하면서 player_date 인덱스를 제거한 후입니다주의) 그 MEMORY 스토리지 엔진의 사용을위한 우리가 다른 테이블에 대해 말하고 있기 때문에 테이블 중 하나가 전혀 문제가되어서는 안됩니다.

또한 색인의 가장 왼쪽 접두어를 정확하게 사용하는 방법에 동의 할 수 있으며 기본 키를 다른 색인과 완전히 똑같이 사용할 수없는 이유를 생각할 수 없습니다. .

이것은 머리를 깎는 사람입니다. 생성 한 새 색인은 기본 키의 왼쪽과 같아야합니다. 그러면 같은 방식으로 작동하지 않는 이유는 무엇입니까? 나는 두 가지 생각을 가지고 있습니다. InnoDB를 사용하면서 MyISAM의 내부에 친숙하지는 않지만 동일한 권장 사항으로 안내합니다. (제쳐두고 MyISAM을 통해 InnoDB를 권하고 싶습니다.)

데이터를 삽입하기 시작했을 때 기본 키의 인덱스는 아마도 테이블에 있었고 새 인덱스는 추가되었지만 대부분의 데이터는 이미 그곳에. 이는 새 색인이 좋고 내부적으로 체계적으로 구성되어있는 반면 기본 키 색인은 데이터가로드 될 때 작성된 상태로 세분화되어있을 수 있음을 나타냅니다.

옵티마이 저가 표시하는 행 계수는 인덱스 통계를 기반으로하며 삽입 순서로 인해 기본 키가 부정확 할 수 있습니다.

조각화 이론은 기본 키를 인덱스로 쿼리하는 것이 왜 그렇게 빠르지 않은지 설명 할 수 있습니다. 인덱스 통계 이론은 왜 옵티마이 저가 다른 행 수인 과을 가져 오는지 설명 할 수 있습니다. 왜 옵티마이 저가 인덱스를 사용하는 대신 전체 테이블 스캔을 선택했는지 설명 할 수 있습니다 (추측 일뿐입니다. 사용 가능한 설명이 없습니다).

이 두 가지 생각을 바탕으로 제안하는 것은 테이블에 OPTIMIZE TABLE을 실행 중입니다. 새 색인을 작성하는 데 12 시간이 걸리면 optimizing the table에 오래 걸릴 수도 있습니다.

아마 도움 : http://www.dbasquare.com/2012/07/09/data-fragmentation-problem-in-mysql-myisam/