我遇到了一些对我来说很陌生的行为。 我正在Windows 7上使用SQL Server 2008 Enterprise，32位（四核2）（用于testing）。
我有一个使用两个表variables的存储过程。 一个插入约2或3行，另一个获得0到100行。 然后我从第二行中选出20-60行，就是这样。
性能相当快。 我创build了一个简单的应用程序循环做查询，我可以做1个线程1300 /秒，4000线程和4线程。
inputtempdb：当我打开资源监视器来查看发生了什么事情时，我发现有很多写入tempdb日志文件。 （我在2个不同的物理磁盘上创build了2个100MB的磁盘 – 它们似乎不会超过100MB。）读取活动为零 – 整个数据块都放在RAM中。
使用单个线程运行查询，大约每秒3MB写入tempdb日志文件。 随着我的增加，每个日志文件上升到20MB /秒。
在SQL活动监视器中，当使用5个线程时，“logging”对于“等待时间”超过300ms /秒。 在3线程，它是下降到25ms /秒。
问：发生了什么事？ 为什么SQL写入tempdb日志像疯了一样，但发出零读取（我看到在资源监视器或活动监视器中没有读取活动）？ 在非testing环境下，在我看来，写入额外的40MB /秒可能会对整体性能造成不利影响。
我知道表variables（@foo）并不总是存储在内存中，但我很困惑，为什么tempdb必须logging所有这些东西。 我怎样才能解决它在做什么？ 我可以把tempdb的日志放在虚拟硬盘上吗？ 任何其他的指针？
提前致谢！
这是典型的日志写入行为。 在数据库中更新页面时，首先将更新写入日志，然后应用于内存页面。 页面在内存中保持脏，直到检查点出现，在此刻写入磁盘。 必须在更新之前写入日志以支持恢复和回滚。 除非发生这两者之一（恢复或回滚），否则不需要再次读取日志。 因此，您看到的行为对于修改tempdb中的页面的系统来说是很典型的。 如果发生回滚，您将只能看到日志读取（因为tempdb无法进行恢复）。
一个更有趣的问题是为什么在tempdb中发生如此多的页面更新？ 典型的罪魁祸首是直接更新（例如，与ASP的tempdb中的会话状态）或间接的（在querry计划中的假脱机和sorting）。