表的重命名会导致索引重建吗？

Question

问题已在标题中，但我会尝试在此提供一些背景信息。

我有一个表 myTable 正在通过 nHibernate 从 Web 应用程序进行查询。它包含 500K 行。 时不时（假设每 15 分钟）我需要刷新此表内容，即删除所有内容并插入另外 500K 行（可能不同）。

免责声明：是的，我知道这不是正确的架构 :-) 不过，无论如何我都需要了解这种行为。

由于插入大约需要 60 秒，我就是这样做的：

1. 在myTable_backup 中插入 500K 行
2. 将myTable 重命名为myTable_temp
3. 将myTable_backup 重命名为myTable
4. 将myTable_temp 重命名为myTable_backup

第 2-4 点旨在快速换桌，因此myTable 几乎总是可用。

尽管我的意图是最好的，但我在尝试访问 myTable 时遇到了 SQL 超时 - 这或多或少会在执行“重命名”时发生。

我的问题是：为什么？

myTable 是否不可用，因为由于 500K 插入，索引仍在其上重建？尽管它已经设法更改了名称，但仍在进行后台重新索引？

如果是这样，是否可以在点 1 和点 2 之间显式执行在 myTable_backup 上重建索引，有帮助吗？

但随后弹出另一个问题，这是我对本文的官方问题：第 3 点）将 myTable_backup 重命名为 myTable 会导致索引重建吗？这对我来说似乎是一个奇怪的想法，但它可以解释我的超时（索引重建大约需要 10 秒）。

你能帮忙吗？如果您不知道答案，或许您可以建议如何找出答案？

谢谢， 公钥簿

Answer 1

不，表的重命名不会导致索引重建。

但它将获得SCH-M（模式修改）锁，为此它需要等待任何现有的读者释放他们的锁。

与此同时，任何新读者都必须在SCH-M 锁定请求后面排队，而不是跳入队列并可能饿死它。 (This is a change in behavior from the previous version)。

您可以检查 sys.dm_os_waiting_tasks 以查看超时期间发生的等待类型。