2009-07-24 107 views
1
Users table 
user_id 
pic_url 
name 

friends table 
auto_id 
userid 
friendid 
status 

actions table 
auto_id 
userid 
type 
subject 
body 
datetime 

我想進行更新,多數民衆贊成的朋友流中顯示的更新,可能是一個博客帖子,狀態變化,任何事情,但應該只表明是從登錄的用戶的朋友的人需要幫助與MySQL連接

這是我想出來的,但我的用戶基數非常大,所以性能是必須的,有沒有更好的方法來做到這一點?請告訴我

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 

請幫助我不認爲這是正確的。

假設有5萬個用戶,我的用戶名爲#1,而我是擁有20,000名用戶的朋友,它應該返回由用戶發佈的用戶發佈的操作表中的所有條目,還需要修改以包含我自己的動作

我聽說過一些人使用某種哈希表進行快速查找會有這樣的事情嗎?

感謝所有幫助

回答

3

我聽到有些人talki約 使用某種哈希表的 更快的查找速度會像 這是可能的嗎?

這就是所謂的index,你應該添加一個到你在使用JOIN(或類似>, >=, =, <=, <一個明確的約束或在規定列表只匹配項目的IN()條規則)計劃每列。通過這種方式,數據庫服務器可以直接跳轉到索引中的正確條目,而不必對所有表格行進行蠻力搜索。這完全像書中的索引。如果你想在名爲「Knuth」的書中找到頁面,你有兩種選擇。如果這本書有索引,你可以查看索引並希望這個名字在那裏。如果這本書沒有索引,那麼你只需要自己閱讀整件事情,而這需要更長的時間。

如果你關心排序/排序(或者做任何類型的相對數字/字符串比較),它應該是一個排序索引。否則,它可能是一個散列表索引,對於有很多行的表更快,但不包含排序信息。這些類型的細節可能會根據使用哪種數據庫服務器軟件而具有不同的語法/選項。**(請參閱下面的註釋)

請注意,主鍵已經具有自動生成的索引,因此您不需要必須自己添加一個。另請注意,如果您有多列主鍵,例如(州,城市,郵政編碼),那麼在主鍵的最左邊的子集上將有效地存在索引,例如,你可以免費獲得州和州(州,城市)和(州,城市,郵編)的索引,但是如果你想加入郵編或城市或(城市,郵編),那麼你需要創建自己的索引除了由主鍵提供的那些。

在你的情況,它看起來像你應該在這些列上的索引(我* *列我假設已經是主鍵)。除非您對用戶標識的數字順序有任何意義,否則這些將成爲散列表索引的良好候選者。

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

**對於MySQL,你的條款添加到使用說HASH的哈希表的索引或使用BTREE(用於排序索引)的CREATE INDEX statement ...忽略的rtrees那些用於空間數據。還要注意,MySQL不允許在公共存儲引擎InnoDB和MyISAM上使用HASH索引。需要高性能的真正大型數據集可能需要在具有HASH索引的內存表中鏡像數據。 50,000行,你可能不需要擔心它; BTREE的搜索時間是O(log n),而HASH是O(1),可能沒有太大的差別。 BTREE非常寬,設計不深;要在搜索步驟中進行一次額外比較,您可能需要將行數增加10或100倍。

+2

更多有關索引的閱讀http://www.alistapart.com/articles/indexing-the -web-its-not-just-googles-business/ – 2009-07-24 00:36:21