真实示例中的 MySQL 分区

Question

我想在一款足球奇幻游戏中尝试使用 MySQL Partitioning，该游戏的用户分布在联赛中，每个联赛都有一个用户可以买卖球员的市场。当很多用户同时玩时，我在这张表中遇到了一些僵局(在撰写本文时大约有 50K 联赛，每两天刷新一次，每个联赛大约有 20 名球员在市场上)，所以我在想关于使用 MySQL Partitioning，这是我以前没有使用过的。

这是我要分区的表:

CREATE TABLE `market` (
  `leagueID` int(10) unsigned NOT NULL,
  `playerID` smallint(5) unsigned NOT NULL,
  `userID` int(10) unsigned DEFAULT,
  `price` int(10) unsigned NOT NULL ,
  `date` int(10) unsigned NOT NULL,
  UNIQUE KEY `league_player` (`leagueID`,`playerID`),
  KEY `user_date` (`userID`,`date`)
);

您推荐哪种方法(列、范围、分区数等)？

这是我最初的做法:

ALTER TABLE market
    PARTITION BY HASH(leagueID)
    PARTITIONS 10;

Answer 1

为什么要分区？

我问是因为大多数分区尝试都一无所获。没有性能提升；有时性能下降。特别是 BY HASH 很少有帮助。

你在使用 MyISAM 吗？如果是这样，请切换到 InnoDB。既然你提到了“死锁”，也许你已经在使用 InnoDB 了？分区无助于事务死锁；我们需要查看两个事务中的查询。解决方案可能就像对 IN 列表进行排序一样简单。

但是...无论我们是否“解决”了您今天遇到的死锁，您都需要检查错误并重播被中止的整个事务。这是“解决”死锁的唯一可靠方法。

Datacharmer 的幻灯片为您提供了血淋淋的细节； my blog列出了PARTITIONing 有用的极少数情况，从而使他的大部分幻灯片变得无用。

其他问题...

• 我没有看到 PRIMARY KEY。建议您将 UNIQUE 键更改为 PRIMARY KEY。 InnoDB 确实需要 PK。
• 有一个DATE数据类型；它可能不像某些 INT 那样使用起来笨拙。