mysql like button table id auto_increment 优化答案

【问题标题】：mysql like button table id auto_increment optimizationmysql like button table id auto_increment 优化
【发布时间】：2015-05-16 20:26:39
【问题描述】：

我有这张桌子：

CREATE TABLE IF NOT EXISTS `likes` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user` varchar(40) NOT NULL,
  `post_id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

这是一个大商店，它让客户喜欢产品。它记录谁喜欢（用户）和什么（帖子ID）。喜欢脸书。

例如： 1 - 玛丽亚 - 233 2 - 约翰 - 527 ...

所以，1 个赞，1 个记录。

如何优化它？允许许多记录？并尽可能快？

我可以使用 KEY 分区吗？有什么例子吗？ id int(11) 是不是太小了呢？

非常感谢！

【问题讨论】：

是什么让您认为自己的方式存在问题？
@HoboSapiens 谢谢你的回答！是的，问题是，这张桌子会变大，我的问题是，它会支持数百万、数十亿的点赞吗？它不会变慢吗？ int(11) 还是 bigint？我可以将它分区更快吗？或者，我不知道，当它每秒收到多个赞时，我怎样才能改进这个表更快……这样好吗？

标签： mysql auto-increment partitioning

【解决方案1】：

INT，默认为 SIGNED；范围是 -20 亿到 +20 亿。它占用 4 个字节。但是 AUTO_INCREMENT 永远不会是负数，因此 INT UNSIGNED 会更好——范围为 0 到 + 40 亿（仍然是 4 个字节）。

40 亿是世界人口的一半以上。如果您的“赞”数接近这个数量，则说明有人在作弊，您应该堵住这个漏洞。

post_id 同上。和user_id。（哎呀，我有点超前了。）

user VARCHAR(40) CHARACTER SET latin1 -- 如果你希望获得更远接近 40 亿的数据，你需要让中国人、泰国人、韩国人等进来。使用 utf8mb4。

您需要用户注册吗？（否则你怎么能防止有人“塞满投票箱”？）你还有另一张桌子叫Users？它有一个AUTO_INCREMENT？那个 id 是一个 4 字节的 INT UNSIGNED？所以，这里不要使用全名；使用该 ID。更小 --> 更多可缓存 --> 更少 I/O --> 更快。

分区？不，不要在没有首先了解它可以做什么和不能做什么的情况下使用 PARTITIONing。它确实不固有地提供速度；当然不适合这个用例。

引擎=MyISAM。您是否曾经在具有十亿行 MyISAM 表的服务器上发生电源故障？当服务器备份时，它开始抱怨表损坏。你花了几个小时弄清楚这意味着什么。然后你启动修复表。几小时后完成。同时系统不可用。使用 ENGINE=InnoDB。

【讨论】：