我有大约 10 个表，其中记录了日期范围和一些值属于日期范围。
每个表都有一些含义。
例如
费率
start_date DATE
end_date DATE
price DOUBLE
可用性
start_date DATE
end_date DATE
availability INT
然后表日期
day DATE
未来 2 年的每一天的日期在哪里。
最终结果是将这 10 个表连接到日期表。查询需要更长的时间，因为还有一些其他的连接和子查询。
我一直在考虑创建一个更大的表，其中包含每天的所有 10 个表数据，但最终表将有大约 1.5M - 2M 记录。
从测试来看，在此表中搜索而不是连接表并在连接结果中搜索似乎更快（0.2 秒而不是大约 1 秒）。
有没有什么真正的理由为什么有一个包含这么多记录的表是个坏主意？
决赛桌看起来像
day DATE
price DOUBLE
availability INT
谢谢您的意见。
我曾经沿着这条路走了一次，然后就后悔了。
您拥有数百万行的投影这一事实告诉我，一个表中的日期与另一个表中的日期不一致，导致为某些属性创建额外的边界，因为在一个表中所有属性必须共享相同的边界。
我遇到的问题是业务发生了变化，突然间我要处理更多的组合，并且行数激增，大大降低了查询速度。另一个问题是使数据保持最新——我的“超级”表是从单独的表中计算出来的，当它们发生变化时。
我发现将它们分开并将逻辑移动到应用程序层对我有用。
我处理的数据几乎和你的一样，除了我只有 3 个表：我有可用性、定价和利润。事实是这 3 个是不相关的，所以日期范围从不对齐，租给大表中的许多人工行。
这是一个复杂的问题。答案很大程度上取决于使用模式。据推测，大多数值不会每天都在变化。因此，您可能会大大增加数据库的大小。
另一方面，可用性之类的东西可能每天都在变化，因此您的数据库中已经有一个大表。
如果您的使用模式一次只关注一张桌子，我会很想说“别管它”。也就是说，如果它没有损坏，请不要进行更改。如果您的使用涉及对一种记录的多次更新，我倾向于将它们留在单独的表中（因此锁定一种类型的值不会阻止对其他类型的查询）。
但是，您的用法表明您正在组合这些表。如果是这样，我认为将它们每天每件放在一排是有道理的。如果您一次获得连续的天数，您可能会发现在基础表中具有不同的天数会大大简化您的查询。而且，如果您的查询专注于特定的时间范围，您建议的结构会将相关数据保留在缓存中，从而为更好的性能留出空间。
我很欣赏波西米亚人所说的。但是，您已经进入了最低级别的粒度，并看到它对您有用。我认为你应该继续进行重组。