我有几个包含需要导入新格式模式的简单数据的数据库。我想出了一个灵活的模式，但它依赖于旧数据库的关键数据存储在一个表中。该表只有一个主键、一个外键（都是 int 的）、一个日期时间和一个小数字段，但是将两个旧 DB 的行数相加表明这个新表的总行数约为 200,000,000 行。
我该如何处理这么多的数据？这是可以追溯到大约 10 年前的数据，并且确实需要可用。幸运的是，我们将来查询时甚至不需要提取其中的 1%，但它确实需要可访问。
我的想法是基于一年有多个表、（源数据的）供应商等 - 甚至每年有一个数据库，最近 2 年在一个数据库中（其中还包含用于管理的存储过程这一切。）
任何和所有的帮助、想法、建议都非常、深刻、非常感谢，
马特。
最重要的是。考虑分析您的查询并测量您的实际瓶颈在哪里（尝试识别丢失的索引），您可能会看到您可以将所有内容存储在一个表中，或者购买一些额外的硬盘足以获得足够的性能。
现在，对于建议，您是否考虑过分区？您可以为每个时间范围创建分区，或者一个分区包含 1% 的常用数据，另一个分区包含 99% 的数据。
这大致相当于按年份或供应商之类的手动拆分表，但由服务器在内部处理。
另一方面，将表实际拆分为“当前”和“历史”可能更有意义。
另一个可能的大小改进是使用 int（如 epoch）而不是 datetime 并提供从 datetime 转换为 int 的函数，因此具有类似的查询
SELECT * FROM megaTable WHERE datetime > dateTimeToEpoch('2010-01-23')
如果您需要进行复杂的日期时间查询，这种尺寸节省可能会具有成本效益。尽管在多维数据集上，有标准的技术来存储 YYYYMMDD 格式的 int，而不是 epoch。
将这些数据存储在单个表中有什么问题？像 Microsoft SQL 2005 这样的企业级 SQL 服务器可以轻松处理它。
顺便说一句，不要每年做表，每个供应商的表或其他类似的事情。如果您必须存储类似的项目集，则需要一个且只有一个表。设置多个表来存储相同类型的东西会导致问题，比如：
查询将非常难以编写，如果您必须从多个表中查询，性能将会降低。
数据库设计将非常难以理解（特别是因为在不同的地方存储相同类型的项目并不是一件自然的事情）。
您将无法轻松地修改数据库（在您的情况下这可能不是问题），因为您必须更改每个表，而不是更改一个表。
它需要自动化一堆任务。让我们看看你每年有一张桌子。如果在 2011-01-01 00:00:00.001 插入新记录，是否会创建新表？如果您必须创建一个新表，您会在每次插入时检查吗？它将如何影响性能？你能轻松地测试它吗？
如果“最近”和“旧”数据之间存在真实、可见的分离（例如，您必须每天使用仅上个月保存的数据，并且您必须保留所有旧数据，但不要使用它），您可以用两台 SQL 服务器（安装在不同的机器上）构建一个系统。第一个高度可用的服务器将用于处理最近的数据。第二个，较少可用且针对写入进行了优化，将存储其他所有内容。然后，按计划，程序会将旧数据从第一个移动到第二个。
使用如此小的元组大小（2 个整数、1 个日期时间、1 个十进制），我认为拥有一个包含所有结果的表会很好。SQL Server 2005 不限制表中的行数。
如果您走这条路并遇到性能问题，那么是时候寻找替代方案了。在那之前，我会奋力前行。
编辑：假设您使用 DECIMAL(9) 或更小，您的总元组大小为 21 个字节，这意味着您可以将整个表存储在不到 4 GB 的内存中。如果您有一个不错的服务器（8+ GB 内存）并且这是主内存用户，那么表和二级索引可以存储在内存中。这应该确保在填充缓存之前的较慢预热时间之后进行超快速查询。