SQL Server 索引和查询计划器的奇怪问题

Question

几天前我们发生了一系列崩溃和恢复，在这些之后，SQL Server 数据库一直表现得很奇怪。我们知道故障转移集群存在一些问题，因此我们不得不再次启动服务器以最终使数据库看似正常工作。

随之而来的问题之一是，我们运行了一个大脚本，该脚本动态删除现有索引并重新创建它们，唯一的区别是它们现在使用 WHERE 列 NOT NULL 进行过滤。然而，出于某种原因，当我从 SSMS 对象资源管理器中选择 SCRIPT INDEX -> CREATE TO -> NEW QUERY WINDOW 时，它提供了基本的索引创建脚本，其中不过滤索引。当我们具有完全权限的客户执行相同操作时，创建脚本会正确显示它已被过滤。

这可能是权限问题（在 Google 上没有找到任何此类问题），还是有可能在脚本正确记录更改时，节点或查询优化器或任何不同步的东西？

类似地，以前执行良好的几个查询（并且仍然在作为此数据库副本的不同数据库中执行良好），现在通过执行计划显示它们的行为有所不同。例如，其中之一有以下问题：

1. 默认情况下，执行计划器显示 SQL Server 使用了错误的索引，在嵌套循环中产生了数百万行而不是它应该的 2 行。
2. 另一个索引是正确的，但会产生数百万个嵌套循环，而在此服务器的副本中，我们只能得到 3 个。
3. 当副本被迫使用与第 1 部分中的问题 DB 相同的错误索引时，它仍然只在嵌套循环中返回 2 行。

这些问题的原因可能是什么，甚至如何开始诊断问题？如上所述，数据库是彼此的副本。唯一的区别是问题数据库崩溃了，数据库被移动到故障转移集群，然后再次返回到正确的节点。索引没有碎片化，统计数据刚刚更新，SQL Server 的查询计划器似乎负载过重。

我真的很感激一些关于可能是什么原因以及我将如何诊断实际问题的专家建议，谢谢。

Answer 1

然而，出于某种原因，当我从 SSMS 对象资源管理器中选择 SCRIPT INDEX -> CREATE TO -> NEW QUERY WINDOW 时，它提供了基本的索引创建脚本，其中不过滤索引。

“出于某种原因”确实如此。如此奇怪和奇怪。您可能在 SSMS 中设置了“服务器版本脚本：SQL Server 2005” Tools > Options > SQL Server Object Explorer > Scripting：

2005 不支持过滤索引，因此WHERE故意省略了该子句。确保设置为 2008 或更好，然后重试。

对于执行不同的查询，您确定数据库相同吗？他们是否使用这些在一个系统上而不是在另一个系统上过滤的索引？两个数据库是否设置为相同的兼容性级别？你更新了副本的统计数据吗？您是否进行了任何索引维护？数据有偏差吗？您是否尝试过重新编译具有最大行为变化的查询？

（这些都是作为问题形成的，但您可以将它们解释为修辞和准建议。）