SQL Server - PK删除性能不佳

时间:2010-10-21 15:56:26

标签: sql sql-server performance sql-server-2008 database-design

我在SQL Server 2008 R2中有一个表,包含大约400行(几乎没有) - 它在主键上有一个聚簇索引(这是一个标识)。该表通过参考完整性(没有级联删除或更新)被大约13个其他表引用。

Inserts / Updates / Gets几乎是即时的 - 我们正在谈论一瞬间(应该是预期的)。但是,使用PK删除时间长达3分钟,我从未见过它超过1.5分钟:

DELETE FROM [TABLE] WHERE [TABLE].[PK_WITH_CLUSTERED_INDEX] = 1

该指数严重分散--90%。我重建并重新组织了该索引(以及该表中的其余部分),但我无法将其降至50%以下。

此外,我将数据库备份/恢复到我的本地PC,我没有删除任何问题 - 不到一秒钟。

我还没有做的一件事是完全删除聚集索引并重新添加它。这本身就是一个问题,因为SQL Server不允许您在其他表引用时丢弃PK索引。

有什么想法吗?

更新

我应该在原帖中加入此内容。执行计划将“责备”置于聚集索引删除--70%。在引用该表的13个表中,执行计划表明没有超过整个查询的3% - 几乎全部都在索引搜索上。

4 个答案:

答案 0 :(得分:4)

如果删除行,则数据库必须检查13个表中没有一个引用该行。那些引用要删除的表的其他表上的外键列是否有足够的索引?

答案 1 :(得分:1)

好吧,我有一个答案......

首先,我几乎用尽了上述问题中指出的所有选项以及相关联的答案。我没有运气似乎是一个微不足道的问题。

我决定做的是:

  1. 添加临时唯一索引(因此SQL 服务器允许我删除 聚集索引)
  2. 删除聚集索引。
  3. 重新添加聚集索引。
  4. 删除临时唯一索引。
  5. 基本上,我擦除并重新添加聚集索引。我能够从这里拿走的唯一一件事就是索引的一部分或物理存储的位置是“损坏的”(我松散地使用这个术语)。

答案 2 :(得分:0)

也许桌子被生产中另一个耗时的过程所锁定。

答案 3 :(得分:0)

另一个想法是,桌面上是否有删除触发器?它会导致这个问题吗?