J'ai une table MySQL InnoDB avec 1 000 000 d'enregistrements. Est-ce trop ? Ou les bases de données peuvent-elles gérer cela et plus encore ? Je pose la question parce que j'ai remarqué que certaines requêtes (par exemple, obtenir la dernière ligne d'une table) sont plus lentes (en secondes) dans la table de 1 million de lignes que dans celle de 100.
Réponses
Trop de publicités?
OMG Ponies
Points
144785
J'ai une table MySQL InnoDB avec 1000000 registres. Est-ce trop ?
Non, 1 000 000 rangs (AKA records), ce n'est pas trop pour une base de données.
Je pose la question parce que j'ai remarqué que certaines requêtes (par exemple, obtenir le dernier registre d'une table) sont plus lentes (en secondes) dans la table avec 1 million de registres que dans celle avec 100.
Il y a beaucoup de choses à prendre en compte dans cette déclaration. Les suspects habituels sont :
- Requête mal rédigée
- Ne pas utiliser de clé primaire, à supposer qu'il en existe une dans la table.
- Modèle de données mal conçu (structure des tableaux)
- Absence d'index
amir beygi
Points
544
Journeyman Programmer
Points
725
Morgan Tocker
Points
1876
Je pense qu'il s'agit d'une idée fausse très répandue : la taille n'est qu'une partie de l'équation lorsqu'il s'agit de l'évolutivité d'une base de données. Il y a d'autres questions qui sont difficiles (ou plus difficiles) :
-
La taille de l'ensemble de travail (c'est-à-dire la quantité de données à charger en mémoire et à traiter activement). Si vous vous contentez d'insérer des données et de ne rien en faire, le problème est en fait facile à résoudre.
-
Quel est le niveau de concurrence requis ? Y a-t-il un seul utilisateur qui insère/lit ou avons-nous plusieurs milliers de clients qui opèrent en même temps ?
-
Quels sont les niveaux de promesse/durabilité et de constance des performances requis ? Devons-nous nous assurer que nous pouvons honorer chaque engagement ? Est-il acceptable que la transaction moyenne soit rapide, ou voulons-nous nous assurer que toutes les transactions sont fiables et rapides (contrôle de qualité six sigma) ? http://www.mysqlperformanceblog.com/2010/06/07/performance-optimization-and-six-sigma/ ).
-
Devez-vous procéder à des opérations telles que ALTER le schéma de la table ? Avec InnoDB, c'est possible, mais incroyablement lent car il faut souvent créer une table temporaire au premier plan (ce qui bloque toutes les connexions).
Je vais donc indiquer que les deux questions limitatives seront les suivantes :
- Vos propres compétences en matière d'écriture de requêtes et d'indexation.
- Le degré de douleur que vous pouvez tolérer en attendant les instructions ALTER TABLE.
Xepoch
Points
4018
J'ai vu des tables non partitionnées contenant plusieurs milliards d'enregistrements (indexés) qui s'auto-joignaient pour des travaux analytiques. Nous avons fini par les partitionner, mais honnêtement, nous n'avons pas vu beaucoup de différence.
Cela dit, il s'agissait d'Oracle et je n'ai pas testé un tel volume de données dans MySQL. Les index sont votre ami :)
