0

我的问题首先出现，然后我将描述整个情况和当前的解决方案：

Questions.
1. Why could mySQL make enormously lots of continous read|write (300-1000 megaBytes) disk operations?
2. Is DB structure optimal (need advice otherwise)?
3. Do UniqueKey could slow down DB?
4. What could be better solution for the situation?
5. At the end vServer is getting down and I got mail with ~'ETIMEDOUT: Connection timed out - connect (2)'; So maybe issue is not in DB structure but it is some misconfiguration?

情况。终端设备上的用户正在玩游戏，当游戏结束时，他们将游戏记录存储在中央数据库中。用户可以看到按高分排序的高分表。我不能说有很多用户。让我们假设每 1 分钟有 1 个用户。

解决方案。灯。由于用户正在玩几个类似的游戏，因此 DB 中有几个类似的表+视图对。（总共约 25 个表格 + 25 个视图）。大多数表包含约 30 000 条记录。其中 3 个包含多达 150 000 条记录。

为了唯一地存储用户：1user-1record 我做了一个唯一的键 UNIQUE INDEX 用户 ID（用户 ID、游戏名称、游戏类型、记录值）。

由于用户应该看到排序后的值（高分），我为一个表格创建了一个视图，显示了需要什么。所以外部 php 脚本使用视图而不是表。

CREATE TABLE supergameN (
id INT(11) NOT NULL AUTO_INCREMENT,
userid VARCHAR(255) NOT NULL,
username VARCHAR(50) NOT NULL,
gamename VARCHAR(100) NOT NULL,
gametype VARCHAR(100) NOT NULL,
description VARCHAR(100) NULL DEFAULT 'empty',
recordvalue INT(11) NOT NULL,
PRIMARY KEY (id),
UNIQUE INDEX userid (userid, gamename, gametype, recordvalue)
)

CREATE VIEW supergameN_view AS
SELECT 
    id,
    userid,
    username,
    gamename,
    gametype,
    description,
    recordvalue 
FROM supergameN
ORDER BY gametype, recordvalue DESC

提前致谢。亚历克斯。

4

1 回答 1

1

也许不是解决方案，但我注意到了一些事情：

从唯一键中省略recordvalue，否则您将允许每个userid-gamename-gametype组合存在多个记录，只要它们具有不同recordvalue的 s!

通过使用

UNIQUE INDEX userid (userid, gamename, gametype)

您确保每个游戏和用户只存储一个结果。

并且，一些进一步的评论/问题：

  • 你真的需要两列来识别游戏吗？
  • 保存的description内容：是用户还是游戏相关？

也许您可以通过在主表中仅包含一gameid列和（假设描述是指游戏）games具有列gameid, gamename,gametype和description. 然后，当然，不再需要保留id，而是将组合作(userid,gameid)为主键。

于 2013-09-03T11:55:34.410 回答