我正在寻找管理大量日志文件的数据集。我试图保持每月平均 150 万个新事件。我过去使用过访问，尽管它显然不是为了这个，并且管理数据集是一场噩梦，因为我不得不将数据集分成几个月。
在大多数情况下，我只需要过滤事件类型并计算数量。但在我在数据导入方面做大量工作之前，我想看看是否有人可以验证这个 SQL Server 是一个不错的选择。是否有我应该避免的条目限制和存档条目？有存档条目的方法吗？
另一部分是我正在从多个来源输入日志，有这么多条目，将它们全部放入同一个表中是否明智，或者每个来源都应该有自己的表，以加快查询速度？
编辑...
将没有连接，大约有 10 列。数据将通过视图过滤，我很想看看基于一个或多个列过滤的选择查询的结果是否具有合理的响应时间？创建一组视图是否会加快频繁查询的速度？
以我的经验，SQL Server 是一个很好的选择，你绝对可以期待 SQL Server 比 MS-Access 更好的性能，通常有更多的优化方法可供你使用。
正如您所说，我可能会继续将这些东西放入 SQL Server Express 中，希望安装在您可以使用的最好的机器上（尽管您确实提到了只有 2GB 的 RAM）。使用一个表，只要它只代表一件事（我认为飞行员的飞行日志和软件错误日志不会在同一个“日志”表中，作为一个荒谬的人为示例）。检查你的表现。如果这是一个问题，请继续使用适用于您的 SQL Server 版本的任意数量的优化技术。
以下是我最初可能会这样做的方式：
如果您在日志表上使用 PK，则使用非聚集主键创建表——我通常使用标识列来为我提供有保证的事件顺序（与重复的日期时间不同）并显示可能的日志插入失败（缺少标识）。在主日期时间列上设置一个聚集索引（您提到您已经按月拆分成单独的表，所以我假设您也会以这种方式查询）。如果您有一些经常在此表上运行的查询，请务必查看它们，但不要期望通过简单地这样做来加快速度。您很可能希望查看索引表基于这些查询中的 where 子句。在这里，您将向 SQL Server 提供有效运行这些查询所需的信息。
如果您无法通过优化查询、索引、使用尽可能小的数据类型（尤其是在索引列上）和在体面的硬件上运行来获得所需的性能，那么可能是时候尝试分区视图（这需要某种形式的持续维护）或分区表。不幸的是，SQL Server Express可能会限制您对分区的功能，您必须决定是否需要迁移到功能更丰富的 SQL Server 版本。您始终可以使用 Enterprise 评估版或 Developer Edition 测试分区。
更新：
在大多数情况下，我只需要过滤事件类型并计算数量。
由于过去的日志不会改变（有点像过去的销售数据），因此存储过去的汇总数字是这种情况下常用的策略。您可以创建一个表，该表仅存储您每个月的计数，并每月（或每周、每天等）插入一次新的计数，其中包含某种预定的作业。使用 datetime 列上的聚集索引，SQL Server 可以更轻松地从实时表中聚合当前月份的数字，并将它们添加到存储的聚合中，以显示总计数的当前值等。
对我来说，这听起来像是一张表，它需要对您将过滤的列集进行索引。限制通过视图访问通常是一个好主意，并确保您的索引真正被使用。
将每个源放入自己的表中将需要 UNION 稍后在您的查询中，并且 SQL-Server 不是很好地优化 UNION 查询。
“归档”条目当然可以手动完成，方法是将日期范围内的条目移动到另一个表（可以存在于另一个磁盘或数据库上），或者使用“分区”，这意味着您可以放置表的一部分（例如由日期范围定义）在不同的磁盘上。在规划 SQL-Server 安装时，您必须规划分区。
请注意，Express 版本限制为 4GB，因此每月有 150 万行，这可能是个问题。
我有一个像你这样的表，有 2000 万行，如果使用索引，查询甚至连接都没有问题。