Indexing 向SQL表添加聚集索引：对于实时生产系统存在哪些危险？

我负责一个已有10年历史的事务系统，其中大部分业务逻辑都是在数据库级别实现的（触发器、存储过程等）。Win2000服务器，MSSQL 2000企业版。 没有考虑立即更换或更新系统的计划

核心进程是一个执行事务的程序——具体来说，它执行一个具有各种参数的存储过程；让我们称之为

sp\u ProcessTrans

。程序以异步间隔执行存储过程

就其本身而言，一切正常，但在远程工作站上有30个此程序实例，所有这些实例都异步执行

sp_ProcessTrans

，然后从SQL server检索数据。执行非常有规律——每分钟执行0到60次，这取决于程序实例负责的项目

随着10年的数据增长，系统性能大幅下降：原因是

Employee

表上的死锁，特别是死锁等待时间

我发现：

• 在执行

  sp_ProcessTrans

  时，它会从

  员工表中选择7次

• 选择是在不是主键的字段上完成的
• 此字段上不存在索引。因此，每个事务执行7次表扫描

因此，死锁的原因很清楚。我在字段上创建了一个非唯一的有序聚集索引（几乎是唯一的，

NUM（7）

，很少更改）。测试环境立即得到了改善。 问题是我无法在测试环境中模拟死锁。我需要30个工作站，并且我需要在这些工作站上模拟“真实”的活动，所以可视化已经过时了

我需要知道我是否必须安排停机时间。 对于MSSQL来说，创建索引不应该是一项危险的操作，但是在事务仍在进行时，在生产数据库上创建此字段索引是否有任何危险（数据损坏、额外的等待时间等）？我可以在30个站点中选择一个交易相当安静的时间

---

有什么我看不到的隐患吗？（如果出现问题，我不希望恢复数据库。使用10年的数据将花费大量时间。）

数据损坏不应该是一个问题，但是如果尝试向实时生产表添加索引，您可能会遇到问题，因为该表在索引创建期间不会响应查询。创建索引将应用独占表锁，直到完成为止，所需时间将取决于许多因素（尤其是行数）

---

强烈建议定期停机，这也是一个好习惯。很明显，备份已经完成，并且有一个计划，以防您必须撤销您想要的操作。

谢谢，我不确定在创建索引时事务将如何运行；独占锁告诉我我需要知道什么。我会安排一些实施的停机时间（以前的管理员经常在工作时间动态地进行更改，很多时间都没有测试。要将这个怪物链接起来，这将是一条漫长的道路）。对于我来说，同样的问题，但对于非集群索引。如何影响实时数据？我们需要停机吗？