Question

这个问题已被提出，但我没有找到“1个语音答案”。

做得更好：

1张大表：

user_id | attribute_1 | attribute_2 | attribute_3 | attribute_4

或4个小表： user_id | attribute_1

user_id | attribute_2

user_id | attribute_3

user_id | attribute_4

1张大桌子还是许多小桌子？每个用户只能拥有attribute_X的1个值。我们有大量数据要保存（1亿用户）。我们正在使用innoDB。性能对我们来说非常重要（10 000个查询/秒）。

谢谢！

弗朗索瓦

Answer 1

如果您坚持零，一个或多个原则，即没有这样的东西，其中一个或无限数字，您将始终构建正确的规范化表来跟踪像此

例如，可能的架构：

CREATE TABLE user_attributes (
  id INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
  user_id INT NOT NULL,
  attribute_name VARCHAR(255) NOT NULL,
  attribute_value VARCHAR(255),
  UNIQUE INDEX index_user_attributes_name(user_id, attribute_name)
);

这是基本的键值存储模式，您可以为每个用户提供许多属性。

尽管对此的存储要求高于固定列安排以及attribute1等永久令人沮丧的名称，但在TB级硬盘驱动器时代，成本很小，因此很少成为问题。

通常，您需要为此数据创建一个表，直到插入时间成为问题。只要您的插入速度很快，我就不用担心了。此时，您需要考虑使用分片策略将此数据划分为具有相同模式的多个表，但仅在需要时才这样做。

我认为这将是~10-50万行的阶段，但如果此表中的插入活动量相对较低，则可能会更高。

不要忘记优化读取活动的最佳方法是使用缓存：最快的数据库查询是您未进行的查询。对于那种事情，你通常使用类似memcached的东西来存储先前提取的结果，并且你会在写入时使其失效。

与往常一样，以生产规模对任何提议的架构进行基准测试。

Answer 2

1张大桌子： user_id | attribute_1 | attribute_2 | attribute_3 | attribute_4

将使您的管理更轻松。否则会有太多单独的查找，这也会使编程与数据库复杂化，并有可能增加应用程序错误。

Mysql：多个表还是一个大表？

2 个答案: