如何设计用户历史数据库以提高效率？

[hujiao123]

我自己在设计一个网站中碰到一个问题，想咨询一下大家看看怎么设计能让数据库效率更高。

网站需要实现的功能：
1.网站是一个数独游戏(小游戏)网站，每天会更新20-30期数独小游戏。
2.每期游戏出来后，任何注册用户都可以完成该游戏，并根据完成的时间来获得分数。
3.同一用户重复完成同一游戏不重复计分，只保留第一次的分数。
4.为避免用户时间长了忘记自己是否玩过该游戏，在进入某期游戏页面的时候，如果用户已经完成过该游戏，页面上应有文字提示

目前我的解决方案：
设计3张表
表A UserTable ：用户表 --存放用户信息，用户ID等
表B GameList ：游戏表--存放所有游戏的信息，相关的字段为：
{
gameid 主键
finishedtimes 计数器，记录该游戏已经被完成过多少次
}
表C FinishHistory ：完成游戏的历史--存放谁玩过哪期游戏的信息，相关字段为：
{
gameid 游戏id
userid 用户id
finished date 玩该游戏的时间
}
注：这里只是列了一些相关字段，并不是真实表的全部字段

每次用户进入网站，程序读表B GameList，列出所有游戏和每个游戏被完成的次数，让用户可以权衡先玩哪个游戏。
用户点击游戏进入具体游戏页面，读表C FinishHistory看看用户之前是否玩过该游戏，如果有，就在页面提示。
用户提交游戏的时候同样根据表C FinishHistory判断是否对用户帐户加分。

存在的问题：
随着游戏的增多和玩游戏的用户增多，FinishHistory的记录数理论上等于用户人数*游戏总数。所以这张表的增长速度非常快。
而每次进入游戏，提交游戏都要读这张表，因此这张表成了瓶颈。

所以很想请教一下大家，如何设计数据库才能避免这种瓶颈？不用去读这么一张大表。有没有可能做一个不同的结构或则表设计来避免这种瓶颈的出现?

附：我想过的一些解决方案:
1. 在用户表A中加一个字段，记录所有完成过的游戏ID.
字段内容类似这样： G01|G03|G08
每次用户进入游戏的时候，读取该字段，并和当前游戏ID匹配，如果有匹配则表示用户已经完成该游戏，提示用户。
缺点：游戏量很大，有几千条甚至上万条数据，所以该字段的长度会变成 6char * 10000 字段长度太长了吧？

2. 在游戏表B中加一个字段，记录所有完成过该游戏的用户ID
字段内容类似这样： User001|User002|User006
每次进入该游戏的时候，以用户ID和该字段匹配。
缺点：这个方案应该比上面的要好，因为虽然注册用户多，但是不会每个人都玩，只有活跃客户才会玩游戏，目前一道题平均有几百人玩过。只是用户ID长度*几百，这个长度也不短。

还有其他更好的办法吗？

[hujiao123]

晕倒，没人注意吗？

[jacobsan]

分小表

[hujiao123]

楼上的能具体说说么，
是不是GameID为1-200的游戏完成记录在History1里面，201-400的游戏完成记录在History2里面，这样设计的？

[人鱼传说]

关注中....

[nongly]

楼主原先的设计没什么问题啊

采用1，2方案可能会引出其它问题，更新或删除数据时异常。比如某一时刻，上千个人同时要对游戏表的那个User001|User002|User006字段提交修改。。。。

楼主的问题，先估计数据量大小，服务器性能，数据库，才能决定采用什么解决办法

在FinishHistory表上对gameid 、userid建立索引试看

[hujiao123]

谢谢楼上的。 确实我还没想到这个锁的问题，方案2会有这样的问题。方案1倒应该不会有，但正如我担心的那样，方案1对字段的长度需求更大。

我现在已经在FinishHistory上建了所以了。

但是FinshiHistory的增长速度是几何级的，我目前有几千题，和几千个用户，因此即使我每天新上线10道题目，可能这张表就要增加几百行甚至上千行。出现瓶颈是迟早的事情。即使我有更好的服务器，也只不过是推迟这个瓶颈的出现。

我现在想的是能否有其他的办法，避免这种情况出现。这就是为什么我会想方案1和方案2。方案1和方案2只是多增加一个字段，但是字段的增加和题目的增加速度是一样的，并不会像现在这个方案那样几何级增长。