Dois-je casser une table mysql plus grande en plusieurs?

Question

J'ai un très grand site de type réseau social sur lequel j'ai travaillé pendant environ 2 ans (trafic élevé et 100 de fichiers) J'ai expérimenté ces deux dernières années avec des trucs pour optimiser les performances pour le trafic et j'ai appris lot. Maintenant que j'ai une énorme tâche, je prévois de complètement re-coder mon réseau social, donc je suis en train de re-concevoir des DB MySQL et tout. Voici une photo que j'ai composée d'un couple de tables mysql que j'ai une question au sujet de. J'ai actuellement la table de connexion qui est utilisée dans le processus de connexion, une fois qu'un utilisateur est connecté sur le site, ils ont très rarement besoin de frapper à nouveau la table, sauf si vous modifiez un email ou un mot de passe. J'ai alors une table d'utilisateur qui est fondamentalement les paramètres d'utilisateurs et les données de profil pour le site. C'est là que j'ai des questions, devrait-il être préférable de diviser la table des utilisateurs en tables plus petites? Par exemple si vous regardez la table d'utilisateur vous verrez plusieurs champs que j'ai marqués comme "setting_" devrais-je juste créer une table d'arrangement séparée? J'ai également des champs marqués avec "count" qui pourrait être le compte total des commentaires, des photos, des amis, des messages électroniques, etc. Donc devrais-je créer une autre table pour stocker juste le compte total des choses? La raison pour laquelle je les ai tous sur une table, c'est que je pensais que ce serait mieux si je pouvais réduire les requêtes mysql, au lieu de cliquer sur 3 tables pour obtenir des informations sur chaque chargement de page que je pourrais toucher 1. Désolé, c'est déroutant, et merci pour tous les conseils.

alt text http://img2.pict.com/b0/57/63/2281110/0/800/dbtable.jpg

Answer 1

devrais-je simplement créer une table de réglage séparée?

Alors devrais-je créer une autre table pour stocker uniquement le nombre total de choses?

Il n'y a pas une seule bonne réponse pour cela, cela dépend de la façon dont votre application est en train de faire.

Ce que vous pouvez faire est de mesurer et d'extrapoler les résultats dans un environnement de développement. D'une part, l'utilisation d'une table séparée vous permettra d'économiser de l'espace et le code sera plus facile à modifier. D'autre part, vous pouvez perdre des performances (et vous le pensez déjà) en devant joindre des informations provenant de différentes tables. À propos du décompte Je pense que c'est bien de l'avoir là, même s'il est toujours dit qu'il est préférable de calculer ce genre de choses, je ne pense pas que cette situation vous blesse du tout. Mais, encore une fois, la seule façon de savoir ce qui est le mieux pour vous et votre application spécifique est de mesurer, de profiler et de découvrir les avantages de le faire. Probablement vous ne gagnerez que 2% d'amélioration.

Answer 2

Vous aurez besoin de comparer les résultats des tests de performance entre les éléments suivants:

1. laissant seul
2. casser en deux tables
3. En utilisant différentes requêtes pour récupérer le login données et données de profil (si vous ne le faites pas déjà) avec toutes les données dans le même tableau

En outre, vous pouvez implémenter une sorte de stratégie de mise en cache sur les données de profil si les données d'utilisation suggèrent que cela serait avantageux.

Answer 3

Je ne considérerais pas votre tableau d'utilisateur terrible grand nombre de colonnes, juste mon avis. Je ne diviserais pas non plus cette table en plusieurs tables à moins que vous ne puissiez trouver un cas pour la suppression de la redondance. Peut-être que vous avez beaucoup d'utilisateurs qui ont les mêmes paramètres, ce serait un cas pour casser la table.

Answer 4

Tant que vous n'avez pas SELECT * FROM vos tables, ayant 2 ou 100 champs n'affectera pas les performances. Juste SELECTseuls les champs que vous allez utiliser et vous serez bien avec votre structure actuelle.

Answer 5

Vous devriez ajouter le compteur -colonnes et les horodatages fréquemment mis à jour dans sa propre table --- chaque fois que vous les augmentez, la ligne entière est écrite.

Answer 6

Doit prendre en compte la taille moyenne d'une seule ligne, afin de déterminer si la récupération est coûteuse. En outre, devrait essayer d'utiliser des index comme lors de la recherche de données ... Le plus important est de concevoir correctement, pas seulement de diviser parce que "il semble grand". Peut-être que l'IP ou les IP pourraient aller ailleurs ... dépend des données enregistrées là-bas.

En outre, comme le socialnetworksite en utilisant ces données gère également les processus auth et autorization (devinez donc), la séparation entre les tables de connexion et l'utilisateur devrait offrir une bonne performance, parce que les données sur la connexion est « assez court », alors que l'accès au profil pourrait être fait une seule fois, immédiatement après la connexion réussie. Faites juste les bons trucs pour améliorer les performances de la DB et c'est fait.

(Rappelez-vous de visualiser des tables comme des entités, les nommer comme une entité, et non comme une collection d'entre eux)

Answer 7

Deux choses que vous voulez examiner au moment de décider si oui ou non vous voulez briser une seule table en plusieurs tables est:

1. MySQL aime les petits ensembles de données cohérents. Si vous pouvez structurer vos tables de manière à ce qu'elles aient des longueurs de ligne fixes, cela aidera les performances au coût potentiel de l'espace disque. D'après ce que je peux dire, il est courant de prendre des données de longueur fixe et de les mettre dans sa propre table, tandis que les données de longueur variable iront ailleurs. Dans la plupart des cas, les jointures sont moins performantes que celles qui ne sont pas jointes. Si les données actuellement dans votre table sont normalement accessibles en même temps, cela ne vaudra peut-être pas la peine de les séparer, car vous ralentirez les deux insertions et potentiellement les lectures. Cependant, s'il y a des données dans cette table qui ne sont pas consultées aussi souvent, alors ce serait un bon candidat pour sortir de la table pour des raisons de performance.

Je ne peux pas trouver une ressource en ligne pour étayer cette affirmation suivante mais je me souviens dans un discours de performance MySQL donnée par Pipes Jay qu'il a dit l'optimiseur MySQL a des problèmes une fois que vous obtenez plus de 8 rejoint dans un requête unique (MySQL 5.0. *). Je ne suis pas sûr de la précision de ce nombre magique, mais les jointures prennent généralement plus de temps que les requêtes d'une seule table.