我有一个正在生产的数据库，其中一个表已经变得非常大(积累了大量数据)。
为了提高查询性能，我使用了 sql server 优化器，它建议了一个新索引。
因此，我制作了生产数据库的副本进行测试，它确实提高了性能，但我的问题是创建索引需要大约 24 小时，并且在创建索引时应用程序无法使用。
对于这个特定的应用程序，停机几个小时不是问题，但停机 24 小时就会是问题，我正在寻找一种无需这样做即可创建此索引的方法。
目前我只有一些想法。
一个想法是将备份复制到另一台服务器。应用新索引和任何其他更改。将备份复制回生产服务器。关闭应用程序并合并 self 进行备份以来的所有新数据。
当然，这有其自身的一系列问题，例如必须将数据重新合并在一起，因此我不喜欢这个想法。
这是 SQL Server 2008 标准版。
我通常通过脚本部署数据库更改。
更新: 另一个想法是在几天内将存档数据分块移出主表。然后当表足够小时创建索引。然后慢慢将数据迁移回来。
最佳答案
如果您使用的是 Enterprise，则可以使用 CREATE INDEX 的 ONLINE 选项它构建索引而不在表上保持长期锁定。其使用有一些注意事项；有关详细信息，请参阅链接的文章，您可能会发现性能影响太大。但这是学术性的，正如您所说的您正在使用标准(抱歉一开始就忽略了这一点)。
它是虚拟机这一事实立即让人想到暂时“提升”虚拟机，甚至暂时重新定位到已满的非虚拟机。对于在非常大的表上重建索引，我认为 RAM 和 I/O 速度将是最大的因素； VM是直接使用驱动器还是虚拟化驱动器？您可以暂时将数据转移到物理驱动器吗？诸如此类的事情。
FWIW，你的离线操作的想法正是我在 MySQL 数据库上所做的(从来没有必要在 SQL Server 数据库上这样做):关闭主数据库，获取快照，清除二进制日志/启用二进制日志记录，然后将其重新启动。在单独的机器上创建索引。准备好后，关闭数据库，备份更新的数据库(以防万一)，放回快照，应用二进制日志，然后备份数据库。它真的很容易;我希望您也可以使用 SQL Server 做到这一点。当然，它确实假设您可以在可接受的时间窗口内对(新优化的)表应用 24 小时的二进制日志!
关于sql-server - 在 SQL Server 2008 中将新索引部署到非常大的表的最佳方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2309889/