使用日期字段。由于 SQL 原生支持日期字段，因此可以使用 WHERE 子句轻松过滤特定日期。
这两个字段具有某些优势，可以使其速度更快[...]
您的 SELECT 查询不是瓶颈，所以不必担心这个问题。可读性和实用程序比“感知瓶颈”更重要。
如果您要在日期字段上运行大量操作，那么我建议将其拆分为单独的列，并在表约束或数据访问层中处理数据验证。
例如，按天、月、年构建销售报告时，如果字段被拆分，则效率更高。原因是您不必使用日期时间函数来拆分日期以进行分组。
如果是像生日这样的东西，我可能只会偶尔查询它，那么我就不会担心它，只需将其保留在日期字段中即可。
即使您只需要年份和月份，我仍然会使用日期字段，因为收集所有数据不会有任何损失。作为标准做法，我总是尽可能地收集所有数据。
虽然对您目前可能没有用处，但IBM Informix Dynamic Server支持以下类型：
DATETIME YEAR TO MONTH
这个存储了你想要的 - 年份和月份。它有其用途。DATETIME 类型族包括许多其他类型，偶尔也会有它们的用处 - 还有一些边缘效用的类型，典型的例子是 DATETIME MONTH TO MINUTE。（该类型的缺点是需要冗长的符号来操作它，但是任何或所有 DATETIME 类型都可以执行许多操作。）
在许多 DBMS 中，您可以对列设置约束条件，因此如果您采用两列方法，则应在列上放置一个 CHECK(month_column BETWEEN 1 AND 12) 约束条件，以确保用户未在表中放置无效值。您甚至可以在年份列上应用约束条件。
此外，一些 DBMS 允许您创建用户定义的类型，年-月类型在这些类型中非常简单。当然，具体细节取决于 DBMS。
除非将年份和月份分开存储具有特定的性能优势，否则建议使用日期。关于索引，如果您有两个列，则需要创建一个组合列的索引，而不是仅针对日期列的索引。日期将在内部转换为长整型值，因此所需的存储空间实际上并不是问题。
此外，请考虑两个字段可能带来的维护痛点。您将拥有两个数据库字段，可能是对象上的两个字段或者需要构建/解析月份和年份以便与数据库交互。使用日期保持简单，并让数据库跟踪数据完整性。
我处理类似您描述的数据 - 过期日期，其中日期始终是该月的最后一天，因此我们只需要月份和年份。我们将其存储为日期。
我会保留一个日期时间列和两个计算列，分别是月份和年份（当然要建立索引）。这样既能达到我的目的，又不失优雅。
如果你预计会有这样的查询：“给我所有七月份的行，不管是哪一年的”，使用单独的月份和年份列会更容易编写。为月份列建立一个单独的索引应该可以提高查询速度。
否则，我会选择单个日期列：简单、易懂、内置验证和日期计算函数可用。你唯一需要担心的是，新设计人员可能会想知道为什么所有事件都发生在每个月的第一天。
还有另一个使用单独的月份和年份列的原因，那就是当月份未知时。我曾经在允许“在2009年某个时候”这种即将到来的事件的应用程序中使用过它。在这种情况下，使用月份列中的NULL可以很好地解决问题。除非你想出一些可怕的方法，比如1月2日表示月份未知，否则无法使用日期类型列来实现这一点。
这样想一下：总有一天会有人向你提出一个需求，希望增强应用程序的功能，不仅能保存年份和月份，还要保存日期。
那么，你会为日期再添加一个额外的列吗？
接着，他们可能还会要求你保存时间。
如果你有单独的年/月/日三个列，那么增强功能会有多容易？如果只有一个日期列呢？
基于这个原因，我会选择使用一个日期列。
可能不行，因为SQL Server（Microsoft）中最小的日期时间数据类型是smalldatetime，长度为4个字节。如果您只需要月份和年份，则需要1个字节的月份和2个字节的年份。
EXTRACT(YEAR_MONTH FROM mydate)иҝӣиЎҢжҜ”иҫғе’ҢдҪҝз”ЁDATE_FORMAT(mydate,'%Y-%M')иҝӣиЎҢжҳҫзӨәпјҢиҜ·еҸӮи§Ғж—ҘжңҹеҮҪж•°гҖӮ - KCD