0

我们有一个应用程序执行一个作业来处理来自 mssql 视图的一系列行。这个视图包含很多行，并且插入的数据带有一个设置为标识的附加列（dataid），这意味着我们可以用来知道我们已经通过数据集走了多远。

前段时间，我们在获取数据 ID 大于 y 的前 n 行时遇到了一些问题（y 是我们处理的最后一个最大的最后一个数据 ID）。好像没有按正确的顺序返回行，也就是说我们在抓取一个范围的行时，好像有些行的dataid放错了，也就是说我们实际处理了dataid为100的一行只到了95。

例子

每次紧缩时的窗口/范围为 100 行。但是如果行的 dataid 不是按顺序排列的，那么获取接下来 100 行的查询可能包含一个真正应该在下一次紧缩中找到的 dataid。然后在执行下一次紧缩时将跳过行。

在 dataid 上的 order by 可以解决问题，但这是减慢速度的方式。你们有什么建议可以以更好/工作的方式完成吗？

当我说很多行时，我的意思是几十亿行，是的，如果你认为这绝对是疯狂的，那么你是完全正确的！

我们使用 Dapper 将行映射到对象。这是完全只读的。

我希望这个问题不要太含糊。提前致谢！

4

3 回答 3

2

在 dataid 上的 order by 可以解决问题，但这是减慢速度的方式。

应用适当的索引。

“为什么我的查询很慢”的唯一答案是：如何：优化 SQL 查询。

于 2013-05-14T09:05:49.967 回答
1

不清楚在同一个句子中混合“视图”和“插入”是什么意思。如果您真的是指投影IDENTITY 功能的视图，那么您可以立即停止，它将不起作用。您需要有一个持久的书签才能恢复您的工作。视图在 SELECT 中投影的 IDENTITY 不符合持久性标准。

您需要以在连续读取中持久的明确定义的顺序处理数据。您必须能够读取以给定顺序明确定义边界的键。您需要保留在与批处理行相同的事务中处理的最后一个键。如何达到这些要求，完全取决于您。一个典型的解决方案是按聚集索引顺序进行处理，并记住最后处理的簇键位置。唯一的聚集键是必须的。IDENTITY 属性和它的聚集索引确实满足您需要的条件。

于 2013-05-14T09:43:29.810 回答
0

如果您只想处理最后 100 个，请尝试 1000000，您可以查看对数据进行分区。

在索引中包含其他 999999000000 有什么意义？

于 2013-05-14T09:19:36.417 回答