大家好！
我的客户目前有一个 SQL Server 数据库，它每天执行 3-4 百万次插入，每天的更新次数和读取次数更多。当前数据库的布局很奇怪，恕我直言：传入的数据进入“当前”表，然后每晚的记录被移动到相应的月度表（即 MarchData、AprilData、MayData 等），它们是当前表的精确副本（模式方面我意思是）。读取是从所有月表和当前表的 UNION 视图中完成的，插入和更新仅对当前表进行。有人向我解释说，将数据分成 13 个表的动机是，所有这些表都使用单独的数据文件，并且这些数据文件被写入 13 个物理硬盘驱动器。所以每个表都有自己的硬盘驱动器，据说可以加快视图性能。我什么
我想知道这种方法真的是最好的方法吗？或者我们可以考虑不同的方法吗？请注意，该数据库大约为 300-400 GB，并且每天以 1.5-2 GB 的速度增长。每隔一段时间，我们就会将超过 12 个月的记录移动到单独的数据库（存档）中。
任何见解都受到高度赞赏。
如果您使用的是 MS SQL Server，请考虑Partitioned Tables and Indexes。
简而言之：您可以按某个值（即按年和月）对行进行分组。每个组都可以作为具有自己索引的单独表进行访问。因此，您无需访问所有行即可列出、汇总和编辑 2011 年 2 月的销售额。分区表使数据库复杂化，但在极长的表的情况下，它可以显着提高性能。它还支持“文件组”将值存储在不同的磁盘中。
这个 MS 制造的解决方案似乎与您的非常相似，除了一件重要的事情：它不会在一夜之间移动记录。
有人向我解释说，将数据分成 13 个表的动机是，所有这些表都使用单独的数据文件，并且这些数据文件被写入 13 个物理硬盘驱动器。所以每张桌子都有自己的硬盘，
这是一个声明：工作中的白痴。
表不存储在磁盘上，而是存储在可以跨越多个数据文件的文件空间中。请注意这一点……因此您可以拥有一个文件空间，该文件空间在 13 个磁盘上包含 12 个数据文件，并且一个表将分布在所有 13 个表上。无需玩愚蠢的游戏来分配负载，只需阅读文档即可。
即便如此，我还是严重怀疑 13 盘的速度是否很快。真的。我私下运行了一个较小的数据库（只有 800gb），它有 6 个单独的数据磁盘，我目前的工作任务是三个数字的磁盘（即 100+）。请不要将 13 张光盘命名为大型数据库。
无论如何，应该需要分发数据，而不是 UNION，而是分区表（获得标准的 sql 服务器，尽管是企业版功能）是要走的路。
请注意，该数据库大约为 300-400 GB，并且每天以 1.5-2 GB 的速度增长。
找一个像样的服务器。
我想知道这种方法真的是最好的方法吗？
哦，硬件。获得一个用于数据库的 SuperMicro 盒子，高 2 到 4 个机架单元，SAS 背板，24 到 72 个磁盘插槽。是的，一台一台电脑。
废弃那些显然不应该使用数据库的人提出的每月一次的 blabla table 废话。都在一张桌子上。使用文件空间和多个数据文件来处理将所有表分配到各种磁盘中的负载。除非...
...您实际上意识到像这样运行光盘是严重的忽视。RAID 5 或 RAID 6 或 RAID 10 是有序的，否则当磁盘发生故障时您的服务器可能会关闭，这将发生并且重新安装 600gb 数据库需要时间。我为我的数据磁盘运行 RAID 10，然后私下拥有大约 10 亿行的表（并且在工作中我们每天添加大约这一点）。鉴于数据库的小尺寸，几个 SSD 也会有所帮助....他们的 IOPS 预算意味着您可以使用 2-3 个磁盘并获得更快的速度。如果这不可能，我敢打赌，这些光盘是 7200 RPM 的慢速 3.5" 光盘……升级到企业级光盘会有所帮助。我个人使用 300gb Velociraptors 用于数据库，但需要使用 15k SAS 光盘； )
Anyho，这听起来真的很糟糕。太糟糕了，我要么很高兴我的实习生想出了一些聪明的东西（因为它肯定会超出实习生的头脑），要么我的开发人员会在我发现它的那一刻停止为我工作（基于严重的无能，感觉可以在法庭上自由质疑）
重组它。还要小心任何批处理 - 那些需要错开时间，以免它们与备份重叠。一个简单的低速磁盘只能提供这么多的 IO。