Nombre maximum d'enregistrements dans une table de base de données MySQL

175

Quelle est la limite supérieure d'enregistrements pour la table de base de données MySQL. Je m'interroge sur le champ d'auto-incrémentation. Que se passerait-il si j'ajoutais des millions d'enregistrements? Comment gérer ce genre de situations? THX!

— xpepermint
source

16

Sans parler du 1.21 GIGAWATTS!

— Ben

2

Au moins si la 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 l'utilisation d'InnoDB.

— Jerry Coffin

77

@ Onion-Knight: Je ne suis pas d'accord. Il est normal d'insérer des millions de lignes 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 prend en charge des millions de tables, c'est probablement le signe d'une erreur architecturale.

— Bill Karwin

62

Les types mysql int peuvent faire pas mal de lignes: http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

la intplus grande valeur 4,294,967,295
non signée est la bigintplus grande valeur non signée est18,446,744,073,709,551,615

— KM.
source

8

2147483647 max, vous n'avez donc à faire l'auto-incrémentation bigint que si vous travaillez avec plusieurs milliards d'entrées? (ce qui ferait probablement fondre vos déclarations sélectionnées bien avant)

— Kzqai

2

@Tchalvak c'est pour un int signé, veuillez lire la documentation mysql.

— Leandro

8

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 limitations d'autres ressources

— KM.

21

L'affiche ne pose aucune question sur les types de données numériques ou autres. . Je ne comprends vraiment pas comment cela peut être signalé comme une réponse correcte. Bien que je doive admettre que la question est ambiguë, nous devons faire la distinction entre le type de données PK et le nombre maximum de lignes pour une table.

— Bery

1

@Bery, l'OP a distingué ce qu'ils recherchaient en le sélectionnant comme réponse. Apparemment, ils étaient intéressés par la capacité du champ d'incrémentation automatique, que ma réponse couvre, et non par les limites des autres ressources.

— KM.

238

La plus grande valeur d'un entier a peu à voir avec le nombre maximum de lignes que vous pouvez stocker dans une table.

Il est vrai que si vous utilisez un int ou bigint comme clé primaire, vous ne pouvez avoir que le nombre de lignes que le nombre de valeurs uniques dans le type de données de votre clé primaire, mais vous n'avez pas à faire de votre clé primaire un entier , vous pouvez en faire un CHAR (100). Vous pouvez également déclarer la clé primaire sur plusieurs colonnes.

Il existe d'autres contraintes sur la taille de la table en plus du nombre de lignes. Par exemple, vous pouvez utiliser un système d'exploitation qui a une limite de taille de fichier. Ou vous pourriez avoir un disque dur de 300 Go qui ne peut stocker que 300 millions de lignes si chaque ligne a une taille de 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 prend en charge 2 à ³² lignes par table, mais vous pouvez créer MySQL avec l' --with-big-tablesoption de le faire prendre en charge jusqu'à 2 à ⁶⁴ lignes par table.

http://dev.mysql.com/doc/refman/5.1/en/innodb-restrictions.html

Le moteur de stockage InnoDB ne semble pas avoir de limite sur le nombre de lignes, mais il a une limite de taille de table de 64 téraoctets. Le nombre de lignes dans celui-ci dépend de la taille de chaque ligne.

— Bill Karwin
source

62

merde - j'aurais aimé avoir lu ceci avant ... je viens de dépasser ma taille de 64 terrabytes sur l'une de mes tables et maintenant mon système est si lent!

— JM4

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.

— teynon le

1

@Tom, InnoDB est le moteur de stockage par défaut de MySQL 5.5, et constitue le meilleur choix dans 99% des cas.

— Bill Karwin

2

@ Ext3h, Sphinx Search est généralement un meilleur choix que les index de texte intégral dans MyISAM ou InnoDB.

— Bill Karwin

1

Pour mysql 8, la limite est de 256 To avec une taille de page de 64 Ko.

— UselesssCat

13

Je suggère de ne jamais supprimer les données. Ne dites pas si les tables sont plus longues que 1000 tronquer la fin de la table. Il doit y avoir une véritable logique métier dans votre plan, par exemple depuis combien de temps cet utilisateur est-il inactif. Par exemple, si elle dure plus d'un an, mettez-les dans un autre tableau. Cela se produirait chaque semaine ou chaque mois dans un script de maintenance au milieu d'une période de ralentissement.

Lorsque vous rencontrez de nombreuses lignes dans votre table, vous devez commencer à partager les tables ou à partitionner et à placer les anciennes données dans les anciennes tables par année, telles que users_2011_jan, users_2011_feb ou utiliser des nombres pour le mois. Modifiez ensuite votre programmation pour qu'elle fonctionne 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, puis 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 cela doit être considéré très attentivement afin qu'à l'avenir, il ne soit pas trop coûteux à re-factoriser. Vous pouvez également mettre uniquement les utilisateurs qui viennent sur votre site tout le temps dans une table et les utilisateurs qui ne viennent jamais dans un ensemble de tables archivées.

— PHPGuru
source

1

À cet égard, il est très utile de regarder le partitionnement MySQL: dev.mysql.com/doc/refman/5.6/en/partitioning.html

— Wim Deblauwe

10

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. Ce serait le nombre minimum d'enregistrements utilisant la limite de taille de ligne maximale. Cependant, plus d'enregistrements peuvent être ajoutés si la taille de ligne est plus petite.

— Xylo
source

pour stocker autant de (1 073 741 824) lignes avec une limite de ligne de 65535, quelle taille de disque dur est nécessaire? s'il vous plaît suggérer

— davidb

1

La taille de disque dur requise ne peut pas être déterminée uniquement en fonction 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écessitent un espace supplémentaire. En outre, cela dépendra du nombre et du type des colonnes TEXT et BLOB car la taille varie en fonction du type. Il existe quatre types de colonnes TEXT à savoir, TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT. Il existe également quatre types de colonnes BLOB à savoir, TINYBLOB, MEDIUMBLOB, BLOB et LONGBLOB.

— Xylo

2

Selon la section Évolutivité et limites de http://dev.mysql.com/doc/refman/5.6/en/features.html , prise en charge de MySQL pour les grandes bases de données. Ils utilisent MySQL Server avec des bases de données contenant 50 millions d'enregistrements. Certains utilisateurs utilisent MySQL Server avec 200 000 tables et environ 5 000 000 000 de lignes.

— Les données
source

cela pourrait aider si vous nous indiquez également le type de matériel utilisé par "Ils"

— my account_ram

En effet, vous avez raison. Mais malheureusement, `` ils '' n'ont rien fait sur le matériel

— Données du

@myaccount_ram désolé de nécromancer cela, mais si c'est 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 d'environ 18 milliards de lignes sur 2 instances AWS db.r4.16xlarge (1 lecteur, 1 rédacteur). Chacune des machines avait 64 cœurs de processeur, 488 Go de RAM, une liaison réseau 25 Gbps, 64 To de disque. Cette échelle de base de données poussait à la fois les limites de taille du processeur et du disque et AWS ne fournit pas d'instances optimisées DB plus grandes. Il a été remplacé par un schéma de base de données plus simple qui ne nécessitait pas autant de lignes.

— Skylar Brown

1

Limites de taille de ligne

The maximum row size for a given table is determined by several factors:

La représentation interne d'une table MySQL a une limite de taille de ligne maximale de 65 535 octets, même si le moteur de stockage est capable de prendre en charge des lignes plus grandes. Les colonnes BLOB et TEXT ne contribuent que de 9 à 12 octets à la limite de taille de ligne car leur contenu est stocké séparément du reste de la ligne.
La taille de ligne maximale d'une table InnoDB, qui s'applique aux données stockées localement dans une page de base de données, est légèrement inférieure à une demi-page. Par exemple, la taille de ligne maximale est légèrement inférieure à 8 Ko pour la taille de page InnoDB par défaut de 16 Ko, qui est définie par l'option de configuration innodb_page_size. " Limites des tables InnoDB ».
Si une ligne contenant des colonnes de longueur variable dépasse la taille de ligne maximale InnoDB, InnoDB sélectionne des colonnes de longueur variable pour le stockage externe hors page jusqu'à ce que la ligne rentre dans la limite de taille de ligne InnoDB. La quantité de données stockées localement pour les colonnes de longueur variable stockées hors page varie selon le format de ligne. Pour plus d'informations, voir « Stockage de lignes InnoDB et formats de lignes ».
Différents formats de stockage utilisent différentes quantités de données d'en-tête et de fin de page, ce qui affecte la quantité de stockage disponible pour les lignes.

— Saurabh Chandra Patel
source

1

Lien http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html

Limites de taille de ligne

La taille de ligne maximale pour une table donnée est déterminée par plusieurs facteurs:

La représentation interne d'une table MySQL a une limite de taille de ligne maximale de 65 535 octets, même si le moteur de stockage est capable de prendre en charge des lignes plus grandes. Les colonnes BLOB et TEXT ne contribuent que de 9 à 12 octets à la limite de taille de ligne car leur contenu est stocké séparément du reste de la ligne.

La taille de ligne maximale pour une table InnoDB, qui s'applique aux données stockées localement dans une page de base de données, est légèrement inférieure à une demi-page pour les paramètres de 4 Ko, 8 Ko, 16 Ko et 32 Ko innodb_page_size. Par exemple, la taille de ligne maximale est légèrement inférieure à 8 Ko pour la taille de page InnoDB par défaut de 16 Ko. Pour les pages de 64 Ko, la taille de ligne maximale est légèrement inférieure à 16 Ko. Voir Section 15.8.8, «Limites des tables InnoDB».

Si une ligne contenant des colonnes de longueur variable dépasse la taille de ligne maximale InnoDB, InnoDB sélectionne des colonnes de longueur variable pour le stockage externe hors page jusqu'à ce que la ligne rentre dans la limite de taille de ligne InnoDB. La quantité de données stockées localement pour les colonnes de longueur variable stockées hors page varie selon le format de ligne. Pour plus d'informations, reportez-vous à la Section 15.11, «Stockage de lignes InnoDB et formats de lignes».

Différents formats de stockage utilisent différentes quantités de données d'en-tête et de fin de page, ce qui affecte la quantité de stockage disponible pour les lignes.

Pour plus d'informations sur les formats de lignes InnoDB, voir Section 15.11, «Stockage de lignes InnoDB et formats de lignes», et Section 15.8.3, «Structure physique des lignes des tables InnoDB».

Pour plus d'informations sur les formats de stockage MyISAM, reportez-vous à la Section 16.2.3, «Formats de stockage de table MyISAM».

http://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html

— Md Nazrul Islam
source

-3

Il n'y a pas de limites. Cela dépend uniquement de votre mémoire libre et de la taille de fichier maximale du système. Mais cela ne signifie pas que vous ne devez pas prendre de mesures de précaution pour lutter contre l'utilisation de la mémoire dans votre base de données. Créez toujours un script qui peut supprimer les lignes qui ne sont pas utilisées ou qui gardera le nombre total de lignes dans un chiffre particulier, disons mille.

— 9jamkt
source

8

La suppression de lignes que vous pensez «inutilisées» est dangereuse et cause bien plus de problèmes qu'elle n'en résout. Un développeur précédent sur l'un de mes projets a mis en œuvre un script qui supprimait les paniers de plus de trois jours, pensant qu'il faisait la bonne chose. Devinez quoi, cela cause des problèmes chaque semaine. Ne supprimez les données que si vous en avez vraiment besoin.

— Ben Hitchcock

le pire des cas est lorsque quelqu'un commence à stocker les chemins de fichiers dans une base de données ... foin où sont passés tous mes fichiers de projet .... j'ai un petit projet qui commence à 3,5 millions de fichiers devinez quoi ... ils ne sont pas tous utilisé fréquemment.

— Kendrick