indexing - 向 SQL 表 : what dangers exist for a live production system? 添加聚集索引

Question

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

核心进程是一个执行事务的程序——具体地说，它执行一个带有各种参数的存储过程；让我们称之为 sp_ProcessTrans .程序以异步间隔执行存储过程。

就其本身而言，一切正常，但该程序在远程工作站上有 30 个实例，所有这些实例都异步执行 sp_ProcessTrans然后从 SQL 服务器检索数据。执行非常规律——每分钟 0 到 60 次，具体取决于程序实例负责的项目。

系统性能随着 10 年的数据增长而大幅下降:原因是 Employee 上的死锁，特别是死锁等待时间。 table 。

我发现:

在 sp_ProcessTrans的执行，它从 Employee 中选择表 7 次

选择是在不是主键的字段上完成的

此字段上不存在索引。因此每个事务执行 7 次表扫描

所以死锁的原因是明确的。我在该字段上创建了一个非唯一有序聚集索引(几乎是唯一的， NUM(7) ，很少更改)。测试环境立即得到改善。
问题是我无法在测试环境中模拟死锁。我需要 30 个工作站，而且我需要在这些工作站上模拟“真实”的事件，所以可视化已经过时了。

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

有什么我没有看到的隐藏危险吗？ (如果出现问题，我不期待恢复数据库。10 年的数据需要很多时间。)

Answer 1

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

强烈建议定期停机，这也是养成的好习惯。显然已经采取了备份，并制定了一个计划，以防您必须撤消您的意图。