.net - 在 SQL Server 2008 中处理大量存档记录的最佳解决方案是什么？

Question

我正在开发一个项目来收集未与 .NET 联机的电子银行交易。 这意味着我将获得一些包含前一天交易的文本文件。它总共包含每天大约 2,000,000 行。

我希望在搜索上个月的交易时表现出色(最多 3 秒)，但我希望能够搜索较早的交易(最多 30 秒)。存档搜索基于 CardNumber、TransactionNumber 和 TransactionDate。我的意思是存档搜索场景是静态的，我们不想搜索其他列或获得任何类型的报告。

我在考虑归档策略。

有一些选项:

1. 调整和优化主表上的索引。

2. 对主表进行分区。

3. 每晚将旧交易转移到另一个数据库。

4. 每小时将旧事务移动到文本文件(TextFile、XmlSerialization、BinarySerialization)，然后在内存中搜索。

5. 使用其他开源非 RDBMS 数据库(如文本搜索中的 Lucene 引擎)。

首先，我想知道哪种策略最适合这种情况？

此外，已知数据库引擎(如 SQL Server 2008、Oracle、Sqlite、MySql 等)支持多少条记录？我们什么时候应该考虑表分区？

Answer 1

我绝对认为分区在这里效果最好，可能是每月分区。您可以切换旧分区(随着时间的推移将它们移动到单独的文件组，并将它们标记为只读)但仍然可以查询它们。一天 2MM 行并不是那么大，但是如果你永远在同一个分区中收集它，一些任务/查询最终将无法扩展。您需要非常勤奋地了解如何设置聚簇索引、非聚簇索引和分区方案/函数。如果您还不熟悉分区，我强烈建议您花一些时间熟悉并成为测试/开发/暂存环境中的专家，然后再将其投入生产。 This is probably a good a starting point as any ，但不要害怕在博客中搜索官方文档之外的实用和现实世界的建议。