在SQL Server 2008中将新索引部署到超大表的最佳方法
我有一个生产中的数据库，其中一个表已经变得非常大(大量累积的数据)。
为了提高查询性能，我使用了sql server优化器，它建议使用一个新的索引。
因此，我制作了一个生产数据库的副本进行测试，它确实提高了性能，但是我的问题是，创建索引花费了大约24小时，并且在创建索引时应用程序不可用。
对于这个特定的应用程序，停机几个小时不是问题，但24小时的停机时间才是问题，我正在寻找一种方法来创建这个索引，而不必这样做。
目前我只有几个想法。
一种想法是将备份复制到另一台服务器。应用新索引和任何其他更改。将备份复制回生产服务器。关闭应用程序并合并自我备份以来的任何新数据。
当然，这有它自己的一系列问题，比如必须将数据重新合并在一起，因此我不喜欢这个想法。
这是SQL Server 2008标准版。
我通常通过脚本部署数据库更改。
更新:另一个想法是在几天内将归档数据分块移出主表。然后在表变得足够小时创建索引。然后慢慢地将数据迁移回来。
回答 4
Stack Overflow用户
发布于 2010-02-22 18:01:44
考虑到虚拟机上缺乏可用的处理能力，再加上毫无疑问相当糟糕的IO吞吐量，我实际上会考虑计算备份、恢复到一台一般的服务器、索引，然后备份/恢复回虚拟机所需的时间。
为了避免初始备份花费很长时间，您可以备份一天，然后在一天中移动它，然后在维护窗口开始时，备份事务日志并将其移动-在此基础上，移动的时间会更短。(这假设是批量/完整日志模式)
Stack Overflow用户
发布于 2010-02-22 17:34:07
如果您使用的是企业版，则可以使用CREATE INDEX的ONLINE选项来构建索引，而无需在表上保留长期锁。关于它的使用有一些警告；有关详细信息，请参阅链接文章，您可能会发现对性能的影响太大。但正如您所说的那样，它是学术性质的(很抱歉一开始没有提到)。
它是一个VM，这一事实立即让人想到是暂时“提升”VM，甚至是暂时迁移到最大容量的非VM。对于在非常大的表上重建索引，我认为RAM和I/O速度将是最大的因素；虚拟机是直接使用驱动器还是虚拟化驱动器？您是否可以将数据临时重新定位到物理驱动器？诸如此类的事情。
顺便说一句，你的“离线后再做”的想法正是我在MySQL数据库上要做的(在SQL Server数据库上从来没有这样做过)：关闭主数据库，获取快照，清除binlog/启用binlog，然后重新启动它。在单独的机器上创建索引。准备好后，关闭数据库，备份更新后的数据库(以防万一)，放回快照，应用binlog，然后恢复数据库。这真的很简单；我希望您也可以使用SQL Server来做到这一点。当然，它确实假设您可以在可接受的时间窗口内对(新优化的)表应用24小时的binlog！
Stack Overflow用户
发布于 2013-05-30 04:44:38
为什么不对表进行分区，并对每个分区进行索引。通过这种方式，您只需对小部分进行索引，然后您就可以在以后合并分区。
https://stackoverflow.com/questions/2309889
复制相似问题