Quand cette table MySQL devient lente

Le tableau ci-dessous est:Quand cette table MySQL devient lente

recherché seulement [sélection simple], sans suppression/insertion/joindre à d'autres, etc.
colonnes sont définies/aucun changement ici
99% + des recherches de temps sera par une même colonne, qui est indexé (colonne: « clé » dans l'exemple)
moteur: MyISAM
format de ligne: dynamique
il y a 2 autres index (colonnes: ID/emplacement)

Étant donné que cette table sera utilisée avec chaque chargement de page, je suis concerné par le rapport taille/vitesse. Jusqu'à combien de lignes (en gros) sera-t-il très rapide, puis rapide, puis lent, puis réduit à ramper?

 
[columns name] | [data type]  | [collation] 
id    | int(11)    
name    | varchar(64)  | utf8_general_ci  
key    | varchar(64)  | utf8_general_ci | [ 99% used for search: is indexed]  
value   | text    | utf8_general_ci  
identifier_id | int(11)    
sort_order  | int(5)    
last_adjusted | datetime   
location   | varchar(255)  | utf8_general_ci  
group_no   | int(3)

Source

2011-01-06 Jeffz

afficher les résultats d'afficher les index de également une requête typique avec plan expliquer. –

Les tables ne sont pas "lentes". Les requêtes pourraient être. –

@a_horse_with_no_name c'est ce que je voulais dire - accès aux données dans table en fonction de la taille de la table - un raccourci, mais vous avez un point - semble un peu idiot – Jeffz

Cela dépend beaucoup de la configuration de votre serveur.

La quantité de mémoire disponible pour le serveur MySQL est la principale préoccupation, puis le type de stockage pour lequel la table est configurée.

Vous ne spécifiez pas quel type d'index est utilisé, key un index UNIQUE ou quelque chose avec des doublons? Je devinerais au UNIQUE, compte tenu de l'utilisation - cela resterait rapide pendant une période très longue. Si vous gardez à l'esprit que l'efficacité est approximativement o (log n) pour rechercher un index unique, et que la recherche elle-même sur un tel index est relativement triviale, alors l'index devrait être hors de la mémoire principale et sur certains médias pour faire beaucoup de différence.

Source

2011-01-06 00:24:45 Orbling

Je n'ai pas accès à la mémoire de MySQL pour le moment, mais c'est sur localhost VDS 1024/50. Correction également: les recherches vont à 2 colonnes (2nd: identifiant_id), les index bot ne sont pas uniques. QUESTION: est 20.000 lignes encore une limite sûre? (Ball Park est ce que je cherche car je vais le tester quand le projet est terminé) – Jeffz

@Jeffz: Voulez-vous dire deux colonnes à la fois, ni unique - ou deux colonnes dans différentes recherches? 20 000 enregistrements avec cette taille de table donneraient un index assez petit, même sur ces champs de texte, seulement quelques Mo. Ce ne serait pas un problème pour la plupart des serveurs. – Orbling

merci pour le temps que vous prenez -> deux colonnes à la fois, ni unique est le cas - j'ai besoin de cette table pour être "snappy" - donc je considère aussi séparer le contenu en tables séparées - avec identifiant_id comme point de séparation. Dans ce cas, seule la clé serait recherchée et chaque table ne dépasserait jamais 5K lignes. Mais une telle scission est un problème. C'est la raison de cette question. – Jeffz

Quand cette table MySQL devient lente

Répondre

Questions connexes