我们正在讨论根据快速增长的大小对 SQL Server 2008 中的某些应用程序表进行分区。一个是事件表，通常用于 INSERTS（80% 的查询）或 SELECTS 查找表的主键（20% 的查询）。另一个表是一个“映射”表，它是所有查找主键的 SELECTS。
沿着主键的分区在这里会有帮助吗？我读了很多书，所有经典的分区示例似乎都是按日期分区的数据仓库表。似乎分区有时弊大于利。
你觉得这些表怎么样？
这与我之前的问题有关BIDS 和 SSRS Web Portal 中的运行时截然不同。
我正在努力刷新 BIDS 中的一些报告，因为它们永远运行。我现在注意到，当我在 BIDS 中刷新报告时，查询将遇到 ASYNC_NETWORK_IO 等待。（也是 CXPACKET，但我明白这与其说是原因，不如说是结果）
帖子需要 ASYNC_NETWORK_IO 的帮助似乎表明 SQL Server 正在等待客户端，我假设在这种情况下是我桌面上的 BIDS。
如果可以从这个信息片段中识别出来，那么问题出在哪里？是我的桌面和它缺乏魅力吗？会不会是网络？我的报表是否在报表端做了太多计算？我还应该看哪里？我该如何解决？
我要补充的是，数据通常永远不会完全返回。相反，我收到以下（冗余）错误消息：
本地报告处理期间发生错误。报告处理期间发生错误。抛出了“System.OutOfMemoryException”类型的异常。
我刚刚开始深入研究查询计划，最近了解到“哈希匹配”很糟糕。不过，我知道很少有事情如此绝对，而且我想确定我是否有错误的哈希匹配。
我的查询包含两个表，使用并行性。它在两个表上使用聚集索引查找，然后在这两个查找之后转到具有分区类型散列的并行（重新分区流）步骤。对于一个表，创建一个位图，然后通过哈希匹配将这两个连接（内连接）。
我的理解是，如果要连接的数据是有序的，则将使用合并连接 - 这是更可取的。聚集索引搜索是有序的。
所以...我想我只是在寻找有关这种情况的一些信息。哈希匹配是否总是遵循流的重新分区？重新分区会忽略顺序吗？或者我不应该被这种“邪恶的”哈希匹配所困扰？
谢谢！！
我有一个相当简单的问题，但事实证明它很难搜索。
我需要创建一个将被分区的表，并将（大量）数据加载到其中。
使用分区创建表或在插入数据后添加分区是否更有效？
附加：为了确保我理解完整的图片，如果我要截断这个表然后再次加载（大量）数据，我应该删除分区然后在加载后添加吗？
ADDTION #2：如果我可以按分区的顺序插入数据，我认为这会比不快吗？
我正在尝试做一些非常简单的事情，但我不明白为什么它不起作用。
我有一个列（sysjobschedules.next_run_datefrom msdb），它是一个格式类似于 yyyymmdd 的 varchar。我想将其转换为日期时间。我使用了相当直接的命令，CONVERT(datetime,next_run_date,112)但我不断收到错误算术溢出错误将表达式转换为数据类型日期时间。
此列中的三个不同值是 20120802、20120803 和 20120806。使用上述相同的函数，我能够成功转换所有三个字符串。
我觉得我一定错过了一些明显的东西......？