Question

Users table
 user_id
 pic_url
 name

friends table
 auto_id
 userid
 friendid
 status

actions table
 auto_id
 userid
 type
 subject
 body
 datetime

我想制作一个显示更新的朋友流，可以是博客帖子，状态更改，但只应显示来自登录用户朋友的内容

这是我提出的，但我的用户群非常大，所以性能是必须的，有更好的方法吗？请告诉我

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

请帮助我认为这不正确。

假设有50,000个用户，我的用户ID是＃1，我是拥有20,000个用户的朋友，它应该返回由我是朋友的用户发布的操作表中的所有条目，还需要修改以包含操作来自我自己

我听说有些人谈论使用某种哈希表来加快查找的速度会在这里发生吗？

感谢您的帮助

Answer 1

我听过一些人在说话使用某种哈希表更快的查找会是这样的那可能吗？

它被称为index，您应该使用JOIN（或与>, >=, =, <=, <或IN ()子句等显式约束匹配，为您计划使用的每一列添加一个它只匹配规定列表中的项目）。这样，数据库服务器就可以直接跳转到索引中的正确条目，而不必通过所有表行进行强力搜索。它就像一本书中的索引。如果您想在书中找到名称为“Knuth”的页面，您有两种选择。如果这本书有一个索引，你可以查看索引并希望名称在那里。如果这本书没有索引，你只需要自己阅读整篇文章，这将需要更长的时间。

如果您关心排序/排序（或进行任何类型的相对数字/字符串比较），它应该是一个排序索引。否则它可以是哈希表索引，对于具有大量行的表来说更快，但不包含排序信息。这些类型的详细信息可能具有不同的语法/选项，具体取决于使用的数据库服务器软件类型。**（请参阅下面的注释）

请注意，主键已经有自动生成的索引，因此您不必自己添加索引。另请注意，如果您有多列主键，例如（State，City，Zipcode）然后在主键的最左边的子集上有效地存在索引，例如，您可以免费获得State，（State，City）和（State，City，Zipcode）的索引，但如果您想在Zipcode或City或（City，Zipcode）上加入，那么您需要创建自己的索引除了主键提供的那些。

在你的情况下，看起来你应该在这些列上有索引（我已经* -ed我假设的列已经是主键）。除非您对用户ID的数字顺序有任何重要性，否则这些将是哈希表索引的良好候选者。

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

**对于MySQL，您可以在CREATE INDEX statement中添加一个子句，其中包含USING HASH表示哈希表索引，或者使用BTREE（表示已排序的索引）...忽略RTREE，因为它们用于空间数据。另请注意，MySQL不允许在公共存储引擎InnoDB和MyISAM上使用HASH索引。需要高性能的真正大型数据集可能需要在具有HASH索引的内存表中镜像数据。有50,000行你可能不需要担心它; BTREE的搜索时间是O（log n），而HASH是O（1），并且可能没有那么大的差异。 BTREE很宽，设计不深;要在搜索步骤中进行单独的额外比较，您可能需要将行数增加10或100倍。

需要帮助mysql连接

1 个答案: