使用主键进行查询优化

时间:2011-10-02 14:13:54

标签: mysql sql database database-design

我有一个包含两个表的数据库:一个用于保存每个用户的信息,另一个用于保存每个用户当前正在玩的游戏的信息。每个用户行和每个游戏行都有一个唯一的主ID,这样每当我想要获取特定行时,我都可以通过查询唯一ID来获取它(据我所知,这可以更快,因为行可以通过索引而不是索引来获取通过表中的每一行)

现在,游戏表中的每个条目都包含有关用户的信息,因此如果我想为特定用户获取每个游戏,我将能够。但是,这就是我目前为用户提取每个游戏的方式:

我为每个用':'分隔的用户保存每个游戏的每个唯一ID。然后我拆分此列表并对每个游戏ID进行单独查询。所以我的问题是,使用每个游戏的主ID进行单独的查询是否更有效,或者更好的做法是“SELECT * FROM games WHERE userID ='theUsersID'”。

更简单地说,从长远来看,针对多个唯一ID进行多次查询,或者进行一次查询但是必须查看数据库中的每个条目是否更好?为了了解我的数据库负载,我通常有10,000个用户,每个用户一次大约有10个游戏。因此,对于每个查询使用主键的100,000次查询,或10,000次查询,但必须遍历每个查询的所有行。

感谢。

6 个答案:

答案 0 :(得分:3)

MySQL甚至不会跳过您正在考虑的低音量节拍。允许未来的灵活性你的“每用户游戏”表应该是 UniqueID,UserID,GameID ---以及你可能想要跟踪的每个用户,每个游戏组合的任何其他内容......这是最常见的,上次为特定游戏播放等等。我绝不会建议连接独特的游戏任何分隔符。这样,您就可以轻松查询...

谁喜欢通过查询游戏ID来关注特定游戏,或者普通人喜欢玩多少个不同的游戏......用户中最常见的游戏是什么。

表上有多个索引很简单.. 一个在主要ID(必需)上,一个用户ID和游戏ID(用户优先搜索游戏),另一个用游戏ID和用户ID(用于搜索特定游戏)

答案 1 :(得分:2)

当您执行“SELECT * FROM games WHERE userID ='theUsersID'”时,数据库引擎不必实际查找所有数据库条目。

如果这是一个常见查询,那么userID列应该有一个索引,以便可以快速处理对where的限制。 从长远来看,每个游戏只进行一次查询就会更有效率。

答案 2 :(得分:2)

因此,据我所知,用户与游戏之间存在多种关系。

每个用户都玩很多游戏 每个游戏都有很多用户。

您目前正在将每个用户玩的游戏存储在用户表

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表中扩展列。

此模型可扩展且更易于管理。

希望有道理:)

答案 3 :(得分:0)

SELECT * FROM games WHERE userID = userID将是最好的模型;

如果您需要将多个游戏连接到一个用户,请使用LEFT JOIN,这样您就可以通过一个查询进行操作

游戏表中的

有列id | userID | 在id put上唯一的AI和userID可以是简单的索引

答案 4 :(得分:0)

据我所知,你的表是这样构建的:

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

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

所以,做一个LEFT-Join:

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

可能会帮到你。

在这里,您还可以通过唯一的名称或某事物来选择用户。否则基于Table_User!

问候!

答案 5 :(得分:0)

执行一个大查询而不是许多小查询通常更可取,因为:

  • 它可以在一个数据库往返中执行,而不是很多。当数据库往返需要通过网络时,这一点尤其重要。
  • 允许数据库引擎使用比您在代码中模拟的简单NESTED LOOPS更高级的查询计划(“大”数据库(如Oracle)也能够执行MERGE或HASH JOIN,不确定MySQL。)

在两张桌子上进行JOIN应该可以解决问题。