不一定在数据库中完成。正如您所建议的那样，这很昂贵。尽管db可能是后备存储，但除了最终存储在db之外，还可能使用一种更有效的机制来配合轮询操作，例如将实时状态存储在内存中。
与 每秒 从Table进行SELECT状态 相比，您可以更有效地轮询内存。

就像我在评论中提到的那样，在某些情况下，通过动画来伪造状态更新的外观可以使您受益匪浅，例如采用估算，较少地检查数据源。

编辑

（一种优化方案，可实时使用较少的数据库资源）

与其稍微每隔X秒轮询一次数据库来检查作业状态，不如稍微改变这种情况的行为。每次将作业添加到数据库时，都要读取数据库一次，以将有关 所有
作业的元数据放入缓存中。因此，例如，内存缓存将反映[user49 … user3，user2，user1，userCurrent]
50个用户的作业（如果每个作业1个）。（也许我应该将其写为[job49 … job2，job1，job_current]，但思路相同）

然后，各个用户的网页将轮询始终保持最新状态的缓存。在此示例中，数据库仅被读取到高速缓存50次（每次提交作业一次）。如果这50个用户平均等待1分钟进行作业处理并每秒轮询一次状态，则用户群将轮询缓存总共50个用户x
60秒= 3000次。

在50分钟的时间内，读取的是50个数据库，而不是3000个。
（平均每分钟1个。）缓存始终是最新的，但仍可以处理负载。与考虑为每个用户每秒访问数据库相比，它要可怕得多。您可以在缓存中存储其他统计信息和信息，以帮助进行估算等。只要新的高速缓存提供更高的效率，它就可以替代大量的数据库命中。

注意：缓存是指像应用程序或第三方解决方案这样的全局存储，而不是ASP.NET页面缓存，它很快就会超出范围。使用ASP.NET的机制进行缓存可能不适合您的情况。

另一个注意事项：无论从何处，数据库都会知道何时添加了另一个作业记录，因此触发器可以初始化缓存更新。

尽管有一个好的数据库解决方案，但如此多的频繁轮询的用户可能会导致Web服务器连接出现问题，并且您可能需要根据流量在该级别使用其他解决方案。