Les données d'une seule table MySQL ne doivent pas dépasser 5 millions de lignes : est-ce une valeur empirique ou une règle d'or ?

Aujourd'hui, nous allons discuter d'un sujet intéressant : quelle est la taille des données d'une seule table MySQL avant qu'il soit nécessaire de considérer la sous-base de données et la sous-table ? Certains parlent de 20 millions de lignes, d'autres de 5 millions de lignes. Alors, à votre avis, quelle est la valeur appropriée ?

Il était une fois un dicton largement répandu dans le cercle technologique Internet chinois : si le volume de données d'une seule table MySQL dépasse 20 millions de lignes, les performances diminueront considérablement. En fait, cette rumeur proviendrait de Baidu. La situation spécifique est probablement la suivante : lorsque le DBA a testé les performances de MySQL, il a constaté que lorsque la taille d'une seule table atteignait 20 millions de lignes, les performances des opérations SQL diminuaient fortement. Ensuite, il a été dit que les ingénieurs de Baidu avaient déménagé dans d'autres entreprises du secteur et avaient apporté ces informations avec eux, ce dicton s'est donc répandu dans le secteur.

Plus tard, le « Manuel de développement Java » d'Alibaba a proposé que le partage de bases de données et de tables ne soit recommandé que lorsque le nombre de lignes dans une seule table dépasse 5 millions ou que la capacité d'une seule table dépasse 2 Go. Ceci est soutenu par la règle d'or d'Alibaba. Par conséquent, lorsque de nombreuses personnes conçoivent le stockage de Big Data, elles l'utilisent comme norme pour effectuer des opérations sur les tables.

Alors, selon vous, quelle est cette valeur appropriée ? Pourquoi pas 3 millions de lignes, ou 8 millions de lignes, mais 5 millions de lignes ? Peut-être diriez-vous que cela pourrait être la meilleure valeur de combat réelle d’Ali ? Alors, la question revient : comment cette valeur est-elle évaluée ? Attendez un instant, réfléchissez-y un instant.

En fait, cette valeur n'a rien à voir avec le nombre réel d'enregistrements, mais est liée à la configuration de MySQL et au matériel de la machine. Car, afin d'améliorer les performances, MySQL va charger l'index de la table en mémoire. Lorsque la taille du tampon InnoDB est suffisante, il peut être entièrement chargé en mémoire et il n'y aura aucun problème d'interrogation. Cependant, lorsqu'une base de données à table unique atteint une limite supérieure d'une certaine ampleur, la mémoire ne peut pas stocker son index, ce qui entraîne la génération d'E/S disque par les requêtes SQL suivantes, ce qui entraîne une dégradation des performances. Bien entendu, cela est également lié à la conception de la structure spécifique de la table, et le problème ultime est la limitation de la mémoire. Ici, l'augmentation de la configuration matérielle peut apporter des améliorations immédiates des performances.

Donc, mon point de vue sur la sous-base de données et la sous-table est qu'elles doivent être combinées avec les besoins réels et ne doivent pas être surconçues. La conception de la sous-base de données et de la sous-table ne doit pas l'être. Au lieu de cela, à mesure que l'entreprise se développe, il sera difficile d'envisager le partitionnement des bases de données et des tables pour améliorer les performances du système. À cet égard, le « Manuel de développement Java » d'Alibaba ajoute : Si le volume de données ne devrait pas atteindre ce niveau dans trois ans, veuillez ne pas diviser la base de données en tableaux lors de la création du tableau. Donc, pour revenir à la question initiale, quelle est, selon vous, une valeur appropriée ? Ma suggestion est de faire une évaluation complète basée sur la situation de votre propre machine, si vous n'avez aucune norme en tête, utilisez temporairement 5 millions de lignes comme norme unifiée, ce qui est relativement une valeur de compromis.

Pour plus d'articles techniques liés à MySQL, veuillez visiter la colonne Tutoriel MySQL pour apprendre !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!