ont besoin d'aide avec MySQL rejoint

Question

Users table 
user_id 
pic_url 
name 

friends table 
auto_id 
userid 
friendid 
status 

actions table 
auto_id 
userid 
type 
subject 
body 
datetime 

Je veux faire un flux d'ami des thats des mises à jour montre des mises à jour, pourrait être un billet de blog, changement d'état, quoi que ce soit, mais devrait ne montrer que ceux qui sont d'un ami de l'utilisateur connecté

Voici ce que j'ai trouvé, mais ma base d'utilisateurs est très grande, donc la performance est un must, y at-il une meilleure façon de le faire? Montrez-moi s'il vous plaît

SELECT u.user_id, u.pic_url, u.name, a.auto_id, a.userid, a.type, a.subject, a.body, a.datetime 
FROM actions AS a 
LEFT JOIN users AS u ON u.auto_id=a.userid 
LEFT JOIN friends AS f ON f.userid=a.userid 
WHERE f.friendid=1 //1 would be my user ID 
AND f.status=active 

S'il vous plaît, aidez, je ne pense pas que ce soit correct. Disons qu'il y a 50 000 utilisateurs et mon ID utilisateur est # 1 et je suis ami avec 20 000 utilisateurs, il devrait retourner toutes les entrées dans la table des actions qui est publié par un utilisateur avec qui je suis ami, aussi besoin de modifier pour inclure actions de moi-même

J'ai entendu des gens parler de l'utilisation d'une sorte de table de hachage pour des recherches plus rapides serait quelque chose comme ça ici possible?

Merci pour toute aide

Answer 1

J'ai entendu certaines personnes Talki au sujet en utilisant une sorte de table de hachage pour serait plus rapide quelque chose lookups comme que possible ici?

Il est appelé index, et vous devez ajouter un à chaque colonne que vous prévoyez d'utiliser un JOIN (ou correspondant à une contrainte explicite comme >, >=, =, <=, < ou une clause IN() qui correspond uniquement les éléments dans une liste indiquée) . De cette façon, le serveur de base de données peut accéder directement aux entrées correctes de l'index, plutôt que de devoir effectuer une recherche par force brute dans toutes les lignes de la table. C'est exactement comme un index dans un livre. Si vous vouliez trouver les pages d'un livre dans lequel le nom "Knuth" apparaît, vous avez deux choix. Si le livre a un index, vous regardez dans l'index et espère que le nom est là. Si le livre n'a pas d'index, il vous suffira de lire tout le livre vous-même, et cela prendra beaucoup plus de temps.

Si vous vous souciez de commander/trier (ou de faire n'importe quel type de comparaison numérique/chaîne relative), il doit s'agir d'un index trié. Sinon, il peut s'agir d'un index de hachage, plus rapide pour les tables comportant beaucoup de lignes, mais ne comportant aucune information de tri. Ces types de détails sont susceptibles d'avoir des syntaxes/options différentes selon le type de logiciel de serveur de base de données utilisé. ** (voir note ci-dessous)

Notez que les clés primaires ont déjà un index généré automatiquement, donc vous ne le faites pas. dois en ajouter un toi-même. Notez également que si vous avez une clé primaire à plusieurs colonnes, par ex. (State, City, Zipcode) alors il y aura effectivement des indices sur les sous-ensembles les plus à gauche de la clé primaire, par ex. vous obtenez un index sur State, et (State, City), et (State, City, Zipcode) gratuitement, mais si vous voulez JOIN sur Zipcode ou City ou (City, Zipcode), vous devez créer vos propres index dans plus de ceux fournis par la clé primaire.

Dans votre cas, il semble que vous devriez avoir des index sur ces colonnes (j'ai * -ed les colonnes que je suppose être déjà des clés primaires). Sauf si vous avez une signification sur l'ordre numérique de vos ID utilisateur, ceux-ci seraient de bons candidats pour les index de hashtable.

Users.user_id* 
Friends.user_id 
Friends.friend_id 
Friends.active 
Actions.user_id 

---

** Pour MySQL, vous ajoutez une clause CREATE INDEX statement qui dit HASH pour UTILISATION index Hashtable, ou en utilisant BTREE (pour un index trié) ... ignores RTREEs que ceux-ci sont pour l'espace Les données. Notez également que MySQL n'autorise pas les index HASH sur les moteurs de stockage communs InnoDB et MyISAM. Les ensembles de données vraiment volumineux nécessitant des performances élevées doivent probablement refléter les données sur une table en mémoire avec un index HASH. Avec 50 000 lignes, vous n'avez probablement pas besoin de vous en préoccuper. un temps de recherche de BTREE est O (log n) alors que HASH est O (1) et il n'y a probablement pas beaucoup de différence. Les BTREE sont très larges et conçues pour ne pas être profondes; Pour exiger une comparaison supplémentaire unique dans l'étape de recherche, vous devrez peut-être augmenter le nombre de lignes d'un facteur 10 ou 100.