我的问题首先出现,然后我会描述整个情况和当前的解决方案:
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?
情况。 终端设备上的用户正在玩游戏,当游戏结束时,他们将游戏记录存储在中央DB中。用户可以看到按高分排序的高分表。 我不能说有很多用户。让我们假设每1分钟有1个用户。
解。 灯。 由于用户正在玩几个类似的游戏,因此在DB中有几个类似的表+视图对。 (~25个表+总共25个视图)。大多数表包含约30 000条记录。其中3个包含多达150 000条记录。
为了唯一地存储用户:1user-1record我创建了一个唯一的密钥UNIQUE INDEX userid(userid,gamename,gametype,recordvalue)。
由于用户应该看到排序值(高分),因此我查看了一个显示所需内容的表。所以外部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
提前致谢。亚历克斯。
答案 0 :(得分:1)
也许不是解决方案,而是我注意到的事情:
从唯一键中省略recordvalue
,否则你将允许每个userid-gamename-gametype
组合存在多条记录,只要它们有不同的{{1} }}Š!
使用
recordvalue
您确保每个游戏和用户只存储一个结果。
还有一些评论/问题:
UNIQUE INDEX userid (userid, gamename, gametype)
中保留的内容:用户或游戏相关吗?也许你可以通过在主表中只有一个description
列并(假设描述引用游戏)来标准化一个单独的表gameid
,其中列games
和{ {1}}。然后,当然,不再需要保留gameid, gamename,gametype
,而是将description
组合作为主键。