불필요한 MySQL은 우리가 꽤 큰 것으로부터 우리의 데이터베이스에있는 우리의 테이블 중 하나가

Question

와 indices 지금까지 내가 우리의 코드는 모든 인덱스, 아직 몇 가지 정보를 사용하여 말할 수

show index from entries; 
+---------+------------+----------------------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 
| Table | Non_unique | Key_name        | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | 
+---------+------------+----------------------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 
| entries |   0 | PRIMARY        |   1 | id   | A   | 13538389 |  NULL | NULL |  | BTREE  |   | 
| entries |   0 | index_entries_on_link_and_feed_id  |   1 | link  | A   | 13538389 |  NULL | NULL | YES | BTREE  |   | 
| entries |   0 | index_entries_on_link_and_feed_id  |   2 | feed_id  | A   | 13538389 |  NULL | NULL | YES | BTREE  |   | 
| entries |   0 | index_entries_on_unique_id_and_feed_id |   1 | unique_id | A   | 13538389 |  NULL | NULL | YES | BTREE  |   | 
| entries |   0 | index_entries_on_unique_id_and_feed_id |   2 | feed_id  | A   | 13538389 |  NULL | NULL | YES | BTREE  |   | 
| entries |   1 | index_entries_on_feed_id    |   1 | feed_id  | A   |  81556 |  NULL | NULL | YES | BTREE  |   | 
| entries |   1 | index_entries_on_time     |   1 | time  | A   |  967027 |  NULL | NULL | YES | BTREE  |   | 
| entries |   1 | index_entries_on_created_at   |   1 | created_at | A   |  846149 |  NULL | NULL | YES | BTREE  |   | 
+---------+------------+----------------------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 
8 rows in set (1.35 sec) 

:

/그래서 내가 인덱스를 보여 주었다 : 데이터 자체로 거의 두 배 크다 중복 될 수 있습니다 : index_entries_on_feed_id은 index_entries_on_link_and_feed_id 및 index_entries_on_unique_id_and_feed_id 모두 사용하기 때문에 색인이 중복 될 수 있습니다.

맞습니까?

Answer 1

몇 가지 관찰 ... 이

은 당신이 그들을 삭제할 수 있도록 같은, 심지어 크기가 동일하다 index_entries_on_unique_id_and_feed_id index_entries_on_link_and_feed_id 정말 유일하다면, feed_id가 정말로 필요한지주의 깊게 확인해 볼 것입니다. 하나의 필드를 조회하더라도 성능이 매우 떨어집니다.

id (기본)와 unique_id의 차이점은 무엇입니까?

상대적으로 작은 행에 여러 가지 방법으로 색인을 생성하는 경우 인덱스가 데이터보다 많은 공간을 사용하는 것이 가능합니다.

10M 개의 행은 전체를 스캔하지 않는 한 실제로는 그렇게 크지 않습니다. 어떤 경우에는 너무 큽니다. 쿼리를 제공하면 인덱스를 적절히 사용하므로 다른 100M 행 이상은 중요하지 않습니다.

2 개 또는 3 개의 테이블 조인을 포함하여 다소 복잡한 쿼리를 작성하는 경우 EXPLAIN을 사용하여 쿼리 계획을 확인하는 것이 좋습니다. 복잡한 MySQL 쿼리를 수동으로 튜닝하여 놀라운 개선이있었습니다.

Answer 2

EXPLAIN 다음에 SQL 쿼리를 사용하여 사용 된 인덱스에 대한 정보를 얻을 수 있습니다. 일부 색인을 사용하지 않는 경우 색인을 삭제할 수 있습니다.

또한, 귀하의 지표 :

UNIQUE_ID 경우 : 는