2009-10-13 7 views
0

Nous avons une de nos tables dans notre base de données qui commence à être assez grand: 10M lignes pour les données
2,14 g pour les indices 3,55 gInutiles indices MySQL

J'ai été très surpris de voir que les indices sont presque deux fois plus grand que les données lui-même:/

Alors j'ai montré les 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) 

Pour autant que je peux dire à notre code utilise tous les indices, encore quelques informations pourrait être dupliqué: Je pense que l'index index_entries_on_feed_id pourrait être un doublon puisque les deux index_entries_on_link_and_feed_id et l'utilisent.

Ai-je raison?

+0

Je m'attendrais à ce que MySQL n'utilise * pas * ces autres index car feed_id n'est pas le premier champ en séquence. Vous ne devriez pas être surpris que les index prennent parfois plus d'espace que les données. – Joe

+0

intéressant. Cela signifie-t-il que si je modifie l'ordre dans index_entries_on_link_and_feed_id ou index_entries_on_unique_id_and_feed_id, je n'ai pas besoin de l'index index_entries_on_feed_id? –

Répondre

2

Quelques observations:

Si id_unique est vraiment unique, alors je vérifierais avec attention si feed_id est vraiment nécessaire: même si c'est pour une recherche sur un seul champ, le gain en performance est très faible.

Quelle est la différence entre id (primary) et unique_id?

Il est tout à fait possible que les index utilisent plus d'espace que les données si vous indexez plusieurs lignes d'une rangée relativement petite.

10M lignes n'est pas vraiment très grande, sauf si vous numérisez le tout, auquel cas c'est trop grand. Si vos requêtes utilisent correctement les index, cela ne devrait pas vraiment compter pour 100 autres lignes ou plus. Si vous écrivez des requêtes modérément complexes, impliquant la jonction de 2 ou 3 tables, je vous recommande vivement d'utiliser EXPLAIN pour vérifier le plan de requête. J'ai apporté des améliorations surprenantes à partir du réglage manuel de requêtes MySQL complexes.

+0

Merci Mike. L'identifiant unique_id est en fait 'external data', et donc le nom peut être trompeur. En pratique, nous avons constaté que ce n'est pas vraiment unique dans notre base de données, mais unique dans le contexte des données externes. (Pensez-y comme l'élément si les entrées de flux ATOM par exemple). Ok, alors, je suppose que notre situation est bonne. Nous n'avons pas vraiment d'impact sur les performances jusqu'ici ...c'est juste que je voulais être sûr que nous ne "sur-indexons" pas, pour l'évolutivité future, puisque cette DB a beaucoup d'écritures, et assez peu de sélections (80%/20%), et les écritures sont où le nombre de l'indice est important. –

-1

Vous pouvez utiliser EXPLAIN suivi de vos requêtes SQL pour obtenir des informations sur les indices utilisés. Si certains index ne sont pas utilisés, vous pouvez les supprimer.

En outre, vos indices: index_entries_on_link_and_feed_id index_entries_on_unique_id_and_feed_id

sont les mêmes, même leur taille est la même, de sorte que vous pouvez les supprimer ...

+0

Eh bien, non, ce sont des indices différents! Et ils sont utilisés par différentes requêtes:/et oui, nous avons utilisé EXPLAIN et tous les index sont utilisés ... ce qui ne veut pas dire que si nous en supprimons un, le solveur de requêtes n'essaiera pas d'utiliser -successivement- un autre:/ –

Questions connexes