Quelle est la limite supérieure des enregistrements pour une table de base de données MySQL. Je m'interroge sur le champ d'auto-incrémentation. Que se passe-t-il si j'ajoute des millions d'enregistrements ? Comment gérer ce genre de situation ? Merci !
La plus grande valeur d'un nombre entier n'a pas grand-chose à voir avec le nombre maximal de lignes que vous pouvez stocker dans un tableau.
Il est vrai que si vous utilisez un int ou un bigint comme clé primaire, vous ne pouvez avoir qu'autant de lignes que le nombre de valeurs uniques dans le type de données de votre clé primaire, mais vous n'êtes pas obligé de faire de votre clé primaire un integer, vous pouvez en faire un CHAR(100). Vous pouvez également déclarer la clé primaire sur plus d'une colonne.
Il existe d'autres contraintes sur la taille des tableaux que le nombre de lignes. Par exemple, vous pouvez utiliser un système d'exploitation dont la taille des fichiers est limitée. Ou vous pouvez avoir un disque dur de 300 Go qui ne peut stocker que 300 millions de lignes si chaque ligne fait 1 Ko.
Les limites de la taille de la base de données sont vraiment élevées :
http://dev.mysql.com/doc/refman/5.1/en/source-configuration-options.html
Le moteur de stockage MyISAM supporte 2 32 rangs par table, mais vous pouvez construire MySQL avec le format --with-big-tables option pour qu'il supporte jusqu'à 2 64 rangs par table.
http://dev.mysql.com/doc/refman/5.1/en/innodb-restrictions.html
Le moteur de stockage InnoDB possède un ID de ligne interne de 6 octets par table, de sorte qu'il y a un nombre maximum de lignes égal à 2. 48 soit 281.474.976.710.656.
Un tablespace InnoDB a également une limite de taille de table de 64 téraoctets. Le nombre de lignes entrant dans cette limite dépend de la taille de chaque ligne.
La limite de 64 To suppose une taille de page par défaut de 16 Ko. Vous pouvez augmenter la taille des pages, et donc augmenter le tablespace jusqu'à 256 To. Mais je pense que vous trouverez d'autres facteurs de performance qui rendent cela déconseillé bien avant que vous ne fassiez croître une table à cette taille.
Merde - j'aurais aimé lire ceci avant... je viens de dépasser la taille de 64 terrabytes sur une de mes tables et maintenant mon système est si lent !
2^32 = 4,294,967,295 et 2^64 = 18,446,744,073,709,551,615 donc... La plus grande valeur entière a un peu à voir avec le nombre maximum de lignes. Pas nécessairement la clé primaire.
Les types mysql int peuvent traiter un grand nombre de lignes : http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html
non signé int la plus grande valeur est 4,294,967,295
non signé bigint la plus grande valeur est 18,446,744,073,709,551,615
2147483647 max, donc vous ne devez faire l'auto-incrément bigint que si vous travaillez avec plusieurs milliards d'entrées ? (ce qui ferait probablement fondre vos instructions select bien avant).
Le contexte de la question est de savoir si le champ d'incrémentation automatique peut gérer un grand nombre de lignes, et non les limites des autres ressources.
Je suggère de ne jamais supprimer les données. Ne dites pas que si les tables sont plus longues que 1000, il faut tronquer la fin de la table. Il doit y avoir une véritable logique d'entreprise dans votre plan, par exemple, depuis combien de temps cet utilisateur est inactif. Par exemple, si c'est plus d'un an, mettez-le dans une table différente. Vous pourriez faire en sorte que cela se produise chaque semaine ou chaque mois dans un script de maintenance au milieu d'une période creuse.
Lorsque vous rencontrez trop de lignes dans votre table, vous devez commencer à partager les tables ou à les partitionner et à placer les anciennes données dans les anciennes tables par année, comme users_2011_jan, users_2011_feb ou utiliser des chiffres pour le mois. Changez ensuite votre programmation pour travailler avec ce modèle. Peut-être créer une nouvelle table avec moins d'informations pour résumer les données dans moins de colonnes et ne faire référence aux tables partitionnées plus grandes que lorsque vous avez besoin de plus d'informations, par exemple lorsque l'utilisateur consulte son profil. Tout ceci doit être considéré avec beaucoup d'attention afin que la refonte ne soit pas trop coûteuse à l'avenir. Vous pourriez également ne mettre que les utilisateurs qui viennent tout le temps sur votre site dans une table et les utilisateurs qui ne viennent jamais dans un ensemble de tables archivées.
À cet égard, il est très utile d'examiner le partitionnement de MySQL : dev.mysql.com/doc/refman/5.6/fr/partitionnement.html
Dans InnoDB, avec une limite de taille de table de 64 téraoctets et une limite de taille de ligne MySQL de 65 535, il peut y avoir 1 073 741 824 lignes. Il s'agit du nombre minimum d'enregistrements pour une taille de ligne maximale. Toutefois, il est possible d'ajouter plus d'enregistrements si la taille des lignes est plus petite.
pour stocker un tel nombre de lignes (1 073 741 824) avec une limite de lignes de 65535, quelle taille de disque dur est requise ?
La taille du disque dur nécessaire ne peut pas être déterminée uniquement sur la base du nombre de lignes et de la taille des lignes. La taille de la table elle-même sera de 64 téraoctets. Cependant, les données des colonnes TEXT et BLOB sont stockées séparément de la ligne et nécessiteront un espace supplémentaire. En outre, cela dépendra du nombre et du type de colonnes TEXT et BLOB, car la taille varie en fonction du type. Il existe quatre types de colonnes TEXTE : TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT. Il existe également quatre types de colonnes BLOB, à savoir TINYBLOB, MEDIUMBLOB, BLOB et LONGBLOB.
Selon la section "Scalability and Limits" dans le document intitulé http://dev.mysql.com/doc/refman/5.6/en/features.html , Support MySQL pour les grandes bases de données. Ils utilisent MySQL Server avec des bases de données qui contiennent 50 millions d'enregistrements. Certains utilisateurs utilisent MySQL Server avec 200 000 tables et environ 5 000 000 000 de lignes.
@myaccount_ram Désolé de faire une nécromancie, mais si cela peut être utile, j'ai vu les limites moins théoriques et plus pratiques de la production MySQL en action. J'ai vu une base de données de ~18 milliards de lignes sur 2x db.r4.16xlarge instances AWS (1 lecteur, 1 écrivain). Chacune des machines disposait de 64 cœurs de CPU, 488 Go de ram, un lien réseau de 25 Gbps, 64 To de disque. Cette échelle de BD poussait les limites de taille du CPU et du disque et AWS ne fournit pas de plus grandes instances optimisées pour la BD. Il a été remplacé par un schéma de base de données plus simple qui ne nécessitait pas autant de lignes.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
2 votes
Du moins, si ma mémoire est bonne, la limite est fixée par le moteur de stockage, donc (par exemple) en utilisant MyISAM vous obtenez une limite différente de celle en utilisant InnoDB.
82 votes
@Onion-Knight : Je ne suis pas d'accord. Il est normal d'insérer des millions de rangées dans une seule table, et certaines bases de données ont une limite, donc cela vaut la peine de demander. Si l'on demande si MySQL supporte des millions de tableaux alors c'est probablement le signe d'une erreur architecturale.