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