使用主鍵的查詢優化

我有一個包含兩個表的數據庫：一個保存關於每個用戶的信息，另一個保存關於每個用戶當前正在玩的遊戲的信息。每個用戶行和每個遊戲行都有一個唯一的主ID，因此無論何時我想要獲取特定的行，我都可以通過查詢唯一ID來獲得它（我的理解速度更快，因爲行可以通過索引獲取，而不是要通過表中的每一行）使用主鍵的查詢優化

現在，在遊戲表中的每個條目包含有關用戶的信息，所以如果我想取每場比賽爲特定的用戶我將能夠。然而，這是我目前如何獲取每個遊戲用戶：

我節省每唯一的ID爲每場比賽由分隔每個用戶「：」。然後我分割這個列表併爲每個遊戲ID做一個單獨的查詢。所以我的問題是，爲每個單獨的遊戲使用主ID進行單獨的查詢更有效率，還是更好地執行「SELECT * FROM games WHERE userID ='theUsersID'」。

爲了把它放在一個更通用的形式，是從長遠來看好做幾個查詢對幾個獨特的ID，或者做一個查詢，但不必通過數據庫中的每個條目看？爲了瞭解我的數據庫負載，我通常有10,000個用戶，每個用戶一次約有10個遊戲。因此，比較是使用每個查詢的主鍵的100,000個查詢，或者10,000個查詢，但是必須遍歷每個查詢的所有行。

謝謝。

來源

2011-10-02 jnortey

CSV _（或半colonSV你的情況： - ）_是一個DB一個非常糟糕的主意，它會送你直接到DB地獄。切勿使用它。將這兩部分拆分成不同的列。 – Johan

MySQL甚至不會在您考慮使用的低音量時跳過節奏。讓未來的靈活性。你的「每個用戶的遊戲」表應該是 UniqueID，UserID，GameID ---加上你想跟蹤的每個用戶，每個遊戲組合的其他任何內容...這是最常見的，上次玩特定遊戲，等我永遠不會建議通過任何分隔符連接獨特的遊戲。通過這種方式，您可以輕鬆地查詢......

誰通過查詢遊戲ID，或有多少不同的遊戲不一般的人喜歡玩喜歡一個特定的遊戲...什麼是用戶之間的頂普通遊戲。

簡單的在表上有多個索引.. 一個關於主要ID（必需），一個由用戶ID和遊戲ID（用於優先用戶優先搜索遊戲），另一個由遊戲ID和用戶ID（用於搜索特定遊戲）

來源

2011-10-02 14:19:58 DRapp

我認爲主鍵應該是「用戶ID，遊戲ID」。這也將保證在「按用戶分類的遊戲」表中不存在任何爭執。 – Louis

'一個關於主ID（必需），一個關於用戶ID和遊戲ID（用於優先用戶優先搜索遊戲），另一個關於遊戲ID和用戶ID（用於搜索特定遊戲）'注意MySQL只能每個（子）選擇使用**一個**索引，因此您可能需要使用複合索引。 – Johan

出於某種原因，我認爲數據庫只能有一個索引。我認爲使用多個索引將是解決我的問題的最簡單方法。謝謝。 – jnortey

當你「SELECT * FROM遊戲其中userid =‘theUsersID’」，數據庫引擎不應該有實際查找所有的數據庫條目。

如果這是一個常見的查詢，然後將用戶ID列應該有一個指標，使在那裏的限制，可以快速處理。從長遠來看，每個遊戲只有一個查詢然後一個查詢會更有效率。

來源

2011-10-02 14:18:58 pcalcao

SELECT * FROM games where userID = userID將是最好的模型;

如果你NEDD到多個遊戲連接到一個用戶使用LEFT

加入，讓你將能夠在遊戲桌一個查詢

做到這一點已經foloving列ID | userID | 的ID把獨特的AI和用戶ID可以是簡單的指數

來源

2011-10-02 14:20:38 madcatzx

據我瞭解，你的表建這樣的：

Table_User: 
UserId (PK); 
UserInformation; 
UserInformation2; 
... 

Table_Games: 
GameId (PK); 
UserId (PK); 
GameInformation; 
...

所以，做一個左加入：

SELECT * 
FROM Table_Games G 
LEFT JOIN Table_User U on (U.UserId = G.UserId) 
WHERE UserId = 'MyUserId'

可能會幫助你。

在這裏，你也可以通過一個唯一的名字或者某事來選擇用戶。其他基於Table_User！

問候！

來源

2011-10-02 14:24:27 MJSt

因此，據我所知，用戶和遊戲之間有很多關係。

每個用戶玩很多遊戲每個遊戲都有很多用戶。

，目前正在存儲每個用戶在用戶表

User ID | Games ID's 
1 | 45:23:12 
2 | 23:66:11

扮演的遊戲，所以你的表是不歸。甚至沒有1NF。考慮規範你的數據。

遊戲的一張桌子，你已經有了。用戶的一張桌子，你也有。一膠表，users_games，有：

ID | userID | GameID 
1 | 1 | 45 
2 | 1 | 23 
3 | 1 | 12 
4 | 2 | 23 
5 | 2 | 66 
6 | 2 | 11

因此，對於檢索數據大約一個用戶，您將使用加入

Select GameID from users u join users_games ug on u.id=ug.userID where u.id='2';

，你可以在users_games表擴展列。

此模型將可擴展且更易於管理。

希望是有道理的:)

來源

2011-10-02 14:24:56 Pheonix

表演一個大的查詢，而不是許多小的通常是可取的，因爲：

它可以在短短一個數據庫往返，而不是許多執行。當數據庫往返需要通過網絡時，這一點尤其重要。
允許數據庫引擎使用比您在代碼中模擬的簡單NESTED LOOPS更高級的查詢計劃（Oracle等「大型」數據庫也能夠進行MERGE或HASH JOIN，不確定MySQL）。

做你的兩個表JOIN應該做的伎倆。

來源

2011-10-02 14:34:38

MySQL已經因爲4.x的日子很長的路要走。現在大多數優化都在DB中。 – Johan

使用主鍵的查詢優化

回答

相關問題