相关疑难解决方法(0)

我们开始为 VMware 中的 SQL Server 2016 节点虚拟集群提供一组物理服务器。我们将使用企业版许可证。

我们计划设置 6 个节点，但关于在 CPU 时钟速度与 CPU 核心数方面配置物理服务器的理想方式存在一些争论。

我知道这在很大程度上取决于交易量和存储的数据库数量以及其他特定于软件的因素，但是否有建议的一般经验法则？

例如，双 8 核 3.2 GHz 物理服务器（16 核）是否比双 16 核 2.6 GHz 服务器（32 核）更优惠？

有没有人遇到过进一步深入研究此类主题的白皮书？

简而言之，
哪些因素会影响查询优化器对索引视图索引的选择？

对我来说，索引视图似乎违背了我对优化器如何选择索引的理解。我之前看过这个问题，但 OP 并没有得到很好的接受。 我真的在寻找 guideposts，但我会编造一个伪示例，然后发布带有大量 DDL、输出、示例的真实示例。

假设我使用的是 Enterprise 2008+，理解 with(noexpand)

伪示例

以这个伪示例为例：我创建了一个包含 22 个连接、17 个过滤器和一个跨越 1000 万行表的马戏团小马的视图。这种观点实现起来很昂贵（是的，大写 E）。我将对视图进行 SCHEMABIND 和索引。然后一个 SELECT a,b FROM AnIndexedView WHERE theClusterKeyField < 84. 在我不知道的优化器逻辑中，执行了底层连接。

结果：

• 无提示：4825 次读取 720 行，47 个 cpu 超过 76 毫秒，估计子树成本为 0.30523。
• 使用提示：17 次读取，720 行，4 毫秒内 15 个 cpu，估计子树成本为 0.007253

那么这里发生了什么？我已经在Enterprise 2008、2008-R2 和 2012 中尝试过。根据我能想到的每个指标，使用视图索引的效率要高得多。我没有参数嗅探问题或倾斜的数据，因为这是临时的。

一个真实（长）的例子

除非你是一个受虐狂，否则你可能不需要或不想阅读这部分。

是的
，企业版。

Microsoft SQL Server 2012 - 11.0.2100.60 (X64) 2012 年 2 月 10 日 19:39:15 …

我正在研究使用READPAST提示来减少我们应用程序财务子系统中的资源锁定。

这似乎是一个不错的方法，因为金融交易记录只会被添加，不会被更新或删除。唯一会被跳过的行是插入事务中的全新行；在事务提交之前，它们实际上不存在于外部世界。

但是，我注意到使用我已READPAST提示的索引视图的查询性能较差。比较查询计划，通过提示，查询优化器选择不使用索引视图，而是退回到将其视为常规视图。

我不确定为什么会这样；我想索引视图就像任何其他索引一样，因为键可以在操作期间被锁定，并且添加的READPAST工作方式类似。

SELECT TOP 1 isa.InvoiceId
FROM Financial_InvoiceSummaryAmounts isa WITH (READPAST)
WHERE isa.TotalOwedAmount = 0.0

SELECT TOP 1 isa.InvoiceId
FROM Financial_InvoiceSummaryAmounts isa
WHERE isa.TotalOwedAmount = 0.0

添加NOEXPAND提示似乎也有效，但我有兴趣了解更多关于可能READPAST导致查询优化器首先做出该选择的原因（作为完整答案的一部分）。

在进行计数（聚合）SQL 查询时，在这 3 个数据库系统中，什么可以加快执行时间？我相信很多事情都可以加快速度（硬件之一），但我只是一个新手 DBA，所以我相信我会在这里得到一些答案。我将大约 1.57 亿行迁移到 SQL Server 数据库，并且这个查询需要永远执行。但是在我的源 Netezza 数据库中，它需要几秒钟。

例如：

网易6：

SELECT COUNT(*) FROM DATABASENAME..MYTABLE

甲骨文 11g：

SELECT COUNT(*) FROM MYTABLE

SQL Server 2012：

SELECT COUNT(*) FROM DATABASENAME.[dbo].[MYTABLE]

我有一个内部 Web 应用程序正在运行，每次用户转到“搜索”视图时，它都会查询数据库中的三个不同表，以生成视图中三个下拉列表的值。

它基本上运行一个

SELECT DISTINCT (PortName)
FROM Ports
ORDER BY PortName ASC

但是该表包含约 10'000'000 行，并且负载非常重，这意味着页面的加载时间（由于加载数据下拉列表）可能会超过 10-15 秒。

那么，有没有更好的方法来做到这一点，例如以特定时间间隔运行一些脚本并在不同位置创建一个表/视图/任何内容，以便卸载查询大表，只是为了从 10'000 返回 80 行'000 在主表中？

我有一个在 SQL Server 2008 中运行的查询：

select count(*)
from table1 join
table2 on table1.col1 = table2.col2

在运行此脚本的数据仓库中，一个名为的表thin_table1专门填充table1（我们使用此薄表创建索引视图。阅读此答案了解更多详细信息）。

问题是优化器选择使用thin_table1而不是table1在执行期间。这在 SQL Server 2005 中不会发生。这个新的执行计划不适用于我们当前的操作。

如何在数据库或会话级（或在 SSIS 中）关闭此“传递”功能？我在数据加载期间运行了许多 SSIS 包和存储过程，所以我不想单独接触所有对象。

此时，即使知道该功能称为什么也有助于寻找答案。

编辑：
在 2005 年回过头来看看同样的计划。看起来它确实发生在那里，但它的戏剧性效果要小得多。我认为这是 2008 年的问题，但 2005 年出现了相同的功能。

EDIT2：
这里的 DBA 注意到该计划正在引用索引视图。我们通常在运行时删除索引视图，但在这个测试场景中，它们仍然被构建。看起来当索引视图处于活动状态时，它将在查询执行时使用该视图以及与其关联的任何表。

有没有办法绕过这种对索引视图的自动引用？