我正在开发一个由相当大的SQL Server 2008数据库备份的系统，大约有250个表。在做了一些性能优化后，我发现在许多表中，外键上缺少索引。在详细了解了所有表格之后，我确定了大约150个具有潜在缺失索引的外键。
我知道put an index on every foreign key通常是一种好习惯，而且我也知道外键的索引aren't automatically created。我怀疑那些没有考虑（或意识到......）后者的人是数据库最终处于当前状态的原因。
但由于我甚至不接近数据库优化方面的专家，我认为在开始添加所有这些索引之前我会解决控制问题：
问题：
在向现有数据库添加如此大量的索引时，是否需要特别注意？
我唯一可以想到的是，对于每个索引，您都可以获得插入和更新的潜在性能损失。但对于严格依赖外键列的索引，我认为这不是一个主要问题。此外，我们的数据库并不是真正的插入/更新密集型，这也不是问题的另一个原因。
我或许还可以提到我们使用NHibernate作为我们的ORM层，我猜这是在外键上有好的索引的另一个原因（因为我们通过外键属性访问了很多对象）。
答案 0 :(得分：3)
除了要考虑的明显要点之外，我认为没有什么特别之处：
如果约束已经存在并且只缺少索引，那么您不必担心最大的潜在问题，即您需要检查和修复的无效数据。但我从你的问题中了解到，FK本身已经存在。
答案 1 :(得分：3)
新计划（虽然由于新索引而希望更快）可能会为死锁提供新的机会 - 以前，语句/事务的所有活动仅针对聚簇索引，它现在可以实现部分查询使用锁定来代替新索引。
确保使用真实的数据量和工作负载进行测试。