在1.06亿行表上创建索引
我有一个安装在世界各地的应用程序，它使用SQL版本，从SQLServer2008Express到SQLServer2017企业版。
我尝试过几种方法在一个大表上创建索引(3列包含3列)，其中数据库通常采用简单的恢复模型，但可以作为完整的恢复模型.硬件可能因客户的不同而大不相同：
- 更改表创建索引..。
- 创建一个带有新索引的tmp表，并将数据复制为"insert into“，然后是原始表的一个drop表和一个tmp表的重命名，以替换原来的表。
- 使用新索引创建一个tmp表，并使用PowerShell脚本复制数据，然后是原始表的一个drop表，然后是tmp表的一个重命名，以替换原始表。
其中最快的是第一个选项(创建非聚集索引的传统方法)，它花费了1h15m，记录了1.06亿多一点(该表有200列.不太理想，但这是我正在做的)其他选择花费了三倍的时间和更多的时间)
不幸的是，我不能使用在线功能，因为有各种各样的Server版本，而且在线只适合企业版。
在我的实验室工作一小时十五分钟太长了，我想找出另一种方法来降低它，特别是在我们的下一个应用程序更新中，我们需要创建23个索引.我还没有看到一次需要5-6小时的更新，客户也不会愿意等待5-6个小时的软件更新。
此外，在更新期间，更新将不需要数据库上的任何活动。
我所寻找的只是一些想法，我可以尝试在合理的时间内创建我的索引。没有密码！只是需要理论上的想法。
任何想法都将不胜感激。
回答 1
Database Administration用户
发布于 2018-09-03 19:03:08
我留下这个作为回答，尽管它主要是一个扩展的评论。
您没有提到索引定义，也没有提到要索引的列的类型。您可以说表是200列，但是除非创建聚集索引，否则这不重要。除非您试图在200列上创建非聚集索引。如果是，请重新考虑。
考虑到您正在跨许多不同的版本执行此操作，很可能它们都位于不同的硬件上。在创建索引的情况下，硬件和现有指标将对完成所需的时间产生巨大影响。这并不是说您可以调优索引创建后的查询。同样，Enterprise并行化索引创建的能力也是一个重要因素。
除了硬件之外，系统并发也可以发挥一定的作用，无论是通过阻塞还是通过总体资源使用。你没有提到这些问题，所以对任何想要回答的人来说，这都是一个盲点。
在较新版本的Server中，可以选择在tempdb中创建排序索引。这可能会有所帮助，只要tempdb不是全金属土豆(跨不同环境)。
最后，您没有提到数据库的恢复模型。由于CREATE INDEX 可以最少地记录，如果可能的话，可能值得切换到SIMPLE或BULK LOGGED恢复模式。这将取决于您的RPO和RTO目标，以及它们是否可以作为创建索引的窗口而被取消。
关于步骤2的快速注释与上面的注释有一点关系:如果您创建一个没有索引、然后加载您的数据和create的表，它可能会更快。特别是在SIMPLE或BULK LOGGED中，您可以使用TABLOCK 提示来获得插入和索引创建的最小日志记录。
您的问题可能会因为范围太广而结束，但我希望您发现这个扩展的评论很有帮助。
https://dba.stackexchange.com/questions/216598
复制相似问题
腾讯云开发者
