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

Question

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

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

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

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

我发现了：

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

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

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

有没有我没看到的隐患？ （如果出现问题，我不期待恢复数据库。10 年的数据需要很长时间。）

Answer 1

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

强烈建议安排停机时间，这也是养成的好习惯。显然已经备份了，还有一个计划，以防你不得不撤销你的意图。