如果我有这样的表：
my_table
=======================
id date some_data
把它拉到date自己的桌子上有意义吗？该date字段将使用date数据类型。所以它现在看起来像这样：
my_table
==========================
id date_id some_data
dates
==========
id date
根据 MySQL，date数据类型 = 3 个字节。为了获得相同的结果，最多需要（3 个字节）date_id。MEDIUMINT一个正常INT或BIGINT超过一个DATE类型的存储要求。
单独表的一个缺点是查询会更复杂，因为我要加入另一个表。
date关于是否将字段拆分到自己的表中，是否还有其他需要考虑的后果？我的直觉反应是，除非您处理一小组日期（小到可以使用TINYINTor SMALLINT），否则不值得这样做。
在我看来，这是一个过度思考你的设计的典型例子。
将日期保存在同一个表中，以便它们可以在必要时与其他列轻松索引，并且不会占用 3 倍的字节数，并且不会让未来的开发人员的生活成为地狱。
规范化通常是一个好主意，无论是为了灵活性还是空间。但是规范化“连续”值，例如
DATE、DATETIME、FLOAT等，通常是一个错误。不要这样做。当您决定按日期范围进行过滤时，可能会出现最大的问题，并且您会发现这
JOIN正在扼杀性能。即使您的日期少于 255 个（我在想
TINYINT UNSIGNED），DATE也不值得变成 id。当我们谈论 ids 时，通常它们应该是
UNSIGNEDandNOT NULL。而且几乎从来没有BIGINT保证。