什么工作更快“更长的表更少的列”或“更短的表与更多的列”？

Question

我必须决定如何计划用于存储日期的表格。

我为每个用户提供了大约20个不同的日期，现在估计有10万用户并且还在不断增长。

所以问题是SELECT查询如果我用20个字段创建表格会更快吗？ e.g。

“user_dates”

userId, date_registered, date_paid, date_started_working, ... date_reported, date_fired 20个总字段，表中有100 000条记录

或制作2张表 第一个表“date_types”，包含3个字段和20个以上列名称的记录。

   id, date_type_id, date_type_name

    1       5        date_reported
    2       3        date_registerd
    ...

和第二个表有3个字段的实际记录

“user_dates”

userId, date_type, date
   201       2      2012-01-28
   202       5      2012-06-14
 ...

但随后有2 000 000条记录？

我认为如果我需要添加更多日期，我可以从前端添加更多日期，只需将记录添加到“date_type”表，然后在“user_dates”中使用它，我认为第二个选项更通用现在担心表中有200万条记录的表现。

您认为哪个选项可以更快地运行？

Answer 1

较长的表将具有较大的索引。更宽的表将具有更小的索引但是需要更多的心理空间并且可能具有更多的开销。您应仔细检查您的架构，看看规范化是否已完成。

但是，我会选择第二种选择。这是因为如果字段为空，则不一定必须存在字段。因此，如果用户未被解雇，则无需为他们创建记录。

Answer 2

确定这一点的最佳方法是通过测试。一般来说，你所谈论的数据大小（20个日期列乘100K记录）对于MySQL表来说真的很小，所以我可能只使用一个包含多列的表，除非你认为你将添加新类型的日期字段一直以来都希望有一个更灵活的架构。您只需要确保索引将用于查询中的过滤，排序，加入等所有字段。

您还可以根据要对数据执行的查询类型来了解设计。例如，如果您希望基于字段组合查询数据（即用户具有某个特定日期，而不是其他日期），那么查询可能会在单个表上更加优化，因为您可以使用简单的SELECT ... WHERE查询。使用单独的表，您可能会发现自己需要执行子选择，奇数连接条件或HAVING子句来执行相同类型的查询。

Answer 3

如果日期非常具体，并且用户将填写所有（或大部分）日期，那么我会使用宽表，因为它更容易实际编写查询以获取数据。使用垂直表编写一个询问所有在范围内具有date1且在范围内具有date2的用户的查询要困难得多。

如果您知道需要动态创建日期类型的选项，我只会使用较长的表格。

Answer 4

只要在主表和user_dates表上索引用户ID和日期类型ID，我怀疑你在查询时会发现问题..如果你在任何一种情况下查询整个表，我确定这需要很长时间（主要是为了发送数据）。在任何一种情况下，单个用户查找都是即时的。

不要牺牲这种关系来提高效率;这不值得。

Answer 5

通常我都是双向的：将基本和最常用的属性放在一个表中。创建一个附加属性表以将rarley使用的属性放入其中，然后可以从应用程序层中懒惰地获取该属性。这样，每次获取用户时都不会进行JOIN。