Comment la conception des lignes influence-t-elle les performances de MySQL?

Question

1. J'ai obtenu une table users et un forum, où les utilisateurs peuvent écrire. Chaque action sur le forum utilise la table users. L'utilisateur peut avoir un profil, qui peut être assez grand (50KB). Si je recevais des données aussi volumineuses dans chaque rangée, ne serait-il pas plus rapide d'avoir une table séparée avec les profils de l'utilisateur et d'autres données auxquelles on n'a pas souvent accès? Dans un jeu RPG en ligne, chaque personnage a une longue liste de capacités, par exemple: expérience de pistolets, expérience de mitrailleuses, expérience de lancer de grenades, et 15 autres. Est-il préférable de les stocker dans une chaîne que les nombres séparés par un point-virgule - ce qui prendrait plus d'espace que les entiers, ou devrais-je faire pour chaque capacité domaine individuel? Ou peut-être binaire? (J'utilise C++)

Answer 1

(1) Non en soi, non. Comme le dit stefan, vous ne devriez sélectionner que ce que vous voulez, alors avoir des choses que vous ne voulez pas dans la table n'est pas un problème. Un blob de 50K TEXT n'est qu'un pointeur dans la rangée.

Cependant, il peut y avoir un problème si vous utilisez des tables MyISAM. Dans MyISAM, il n'y a que le verrouillage au niveau de la table, donc quand un utilisateur met à jour sa ligne (par exemple la dernière heure de visite), il empêche tous les autres utilisateurs d'accéder à la table. Dans ce cas, vous pourriez expérimenter une amélioration en séparant les colonnes fortement mises à jour en une table distincte des colonnes relativement statiques mais fortement sélectionnées.

Mais vous ne voulez pas utiliser MyISAM de toute façon: c'est un peu la merde. Utilisez InnoDB, obtenez le verrouillage au niveau de la ligne (et les transactions, et les contraintes de clé étrangère), et ne vous inquiétez pas. La seule raison d'utiliser les tables MyISAM aujourd'hui est la recherche fulltext, que InnoDB ne supporte pas. (2) Vous devez normalement séparer chaque valeur indépendante dans son propre champ. Si vous rencontrez un problème de performance réel et que vous n'avez pas besoin de manipuler les valeurs au niveau de la base de données, vous pourriez envisager de le dénormaliser, mais vous perdriez la puissance de la base de données.

Answer 2

1. Si vous ne avez pas besoin des données de colonnes spécifiques, ne l'obtiennent pas. Ne pas faire SELECT * mais SELECT a, b,...

2. Si vous devez faire des requêtes SQL-sur certaines colonnes par exemple ORDER BY pistols_experience, vous devriez le laisser dans différentes colonnes. Si vous venez de l'afficher à la fois, vous pouvez sérialiser les différentes paires valeur-clé dans un champ texte via YAML, JSON, etc.