【问题标题】:Certain values for WHERE clause involving foreign key are slow涉及外键的 WHERE 子句的某些值很慢
【发布时间】:2012-07-18 19:51:46
【问题描述】:

此查询有效:

SELECT [ID]
  ,[PROJECT_ID]
  ,[NAME]
  ,[LOCATION]
  ,[COMMENT]
FROM table1
WHERE PROJECT_ID = 4479

但这个没有:

SELECT [ID]
  ,[PROJECT_ID]
  ,[NAME]
  ,[LOCATION]
  ,[COMMENT]
FROM table1
WHERE PROJECT_ID = 3560

它无限地旋转和旋转。唯一的区别是使用的值。

“PROJECT_ID”是一个外键,并且有一个用它作为唯一列定义的索引(通常使用 FK)。

并行:此表的 FK 索引上存在大量碎片。

这些可能相关吗,即,如果我重建索引,我应该期望问题会得到解决吗?

我现在无法重建它们,因为它是一个生产系统,我的理解是我只能在可以获得锁时重建索引......比如今晚很晚。

对于如何“强制重建数据库中所有表中的所有索引,即使它断开用户连接”的任何指导也值得赞赏。

谢谢, - 杰西

【问题讨论】:

  • 我已经确认重建索引确实解决了我的问题,一旦我弄清楚如何删除阻塞连接/会话以便通过右键单击 SSMS 中的“索引”来进行重建。谢谢。
  • 您至少可以在白天运行在线索引重组,这样晚上重建期间的工作就更少了。

标签: performance sql-server-2008 indexing foreign-keys rebuild


【解决方案1】:

这些查询是否封装在存储过程中?如果是这样,您可能会受到参数嗅探的影响。

您也可以检查您的统计数据;如果它们非常过时,您可能会得到一个非常糟糕的执行计划,其中某些参数而不是其他参数。

【讨论】:

  • 如果选择性非常不稳定(或者表格太大以至于手动更新统计信息就像用杯子倒掉大海一样),您可能需要在查询中添加OPTION (RECOMPILE),阻止参数嗅探。
  • 谢谢。它与 SP 无关,但如果不是 Index,它肯定至少与 Stats 相关(不确定,因为我的理解是两者都是在重建时完成的。)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-11-21
相关资源
最近更新 更多