我有一个累积快照事实表，用于跟踪终端中容器的进入和退出。

集装箱可以通过3 种不同的方式进出，所以我想创建一个特定的维度表，列出这 3 种可能的方式（火车、船只或卡车）。

然后我读了这篇文章，它基本上说这种技术是错误的，但我不明白为什么。

第一篇：

有时，当事实表有一长列事实且在任何单个行中都稀疏填充时，很容易创建一个度量类型维度，将事实表行折叠为由度量类型维度标识的单个通用事实。我们一般不推荐这种方法。虽然它删除了所有空的事实列，但它将事实表的大小乘以每行中被占用的平均列数，这使得列内计算变得更加困难。当潜在事实的数量非常多（数百个）时，此技术是可以接受的，但适用于任何给定事实表行的数量并不多。

我知道如果为事务事实表实现了“度量类型维度”，它可能会产生像另一篇文章所说的那样的问题，但如果用于累积快照事实，我看不出任何缺点。

第二篇文章：（ 实施“度量类型维度”的一些缺点）

1. [...] 如果我们使用“度量类型维度”，我们将失去这种分析能力。如果一个度量与其他度量不兼容，我们就无法将它们相加。
2. [...] 我们的 SQL 生成报告需要运行的传递次数越多，报告的速度就越慢。
3. [...] 在 BI 工具上，如果您不放置度量类型过滤器，您就有可能让用户获得“垃圾信息”。从可用性的角度来看，这种设计是垃圾。

回应 Mark Storey-Smith 的回答

非常好的方法，我从来没有想过。

另一件事：将集装箱带入码头的车辆的每次进出都有一个唯一的 ID，它为我提供了其他信息，例如：车辆的预计到达时间、实际到达时间、如果是船只、码头、卡车、收费站和许多其他信息...

这是 3 个不同的事实表，它们必须以某种方式链接到容器事实表。

我以为航程的ID是a degenerate dimension，所以它会直接进入容器事实表。所以，我的疑问是：我应该在容器事实表中添加 6 个不同的字段（vessel_voyage_in_key、vessel_voyage_out_key、train_voyage_in_key、train_voyage_out_key、truck_voyage_in_key、truck_voyage_out_key）还是只添加 2 个动态链接到各种航程表的其他字段（voyage_in、voyage_out）？

我希望我的疑问很清楚，谢谢。

我有一个包含 2200 万条记录的表。

我注意到一列的统计数据很差，即使该列具有恒定分布：实际上，每个值都重复两次。

为了帮助您可视化此场景，请考虑一个表，其中包含另一个表的每个唯一 ID 的签入和签出日期（2 个不同的记录）。

这些是完整扫描的统计信息：

这些是自动采样的统计数据：

为什么会有这种奇怪的行为？是否有一些经验法则可以确定正确的采样率，或者是否需要全扫描？我应该为某些统计信息创建一个带有 fullscan 的统计更新作业吗？如果是这样，我怎么知道哪些统计数据需要这种处理？

附加信息：

• 该列没有外键约束
• 该列是一个 numeric(14,0) NULL

我有一个当前保存数百万条记录的日志表。我想在那个表上启用分区，所以我现在做的是：

1. 创建了分区函数和分区方案。
2. 在该分区方案上创建了一个具有相同结构的空表。
3. 从当前日志表复制的数据从这个时间点（让我们称之为T1）倒退到新的分区表。

接下来的步骤将是最后剩余的记录从复制T1到Tnow和重命名这两个表，以便应用程序开始写入新的分区表。

当然日志表经常被访问，所以我的问题是：

如何确保在此过程中不会丢失任何数据？我是否可以做到让用户不会注意到任何事情，或者我是否必须在这短暂的时间内停止应用程序？或者我可以阻止该表以便应用程序继续运行吗？如果是这样，如何？

我发现，通过查询存储，一个查询平均执行 297582 次逻辑读取。

我想看看我是否能够稍微调整该查询，然后尝试再次执行该查询以查看是否有任何改进。

问题是我在缓存计划中找不到编译参数值。

我错过了什么吗？也许是一些阻止参数值缓存的原因/设置？

即使我以 XML 格式打开执行计划，我也找不到参数。

附加信息：查询由第三方应用程序执行，该应用程序准备语句，然后使用sp_prepare和执行它们sp_execute。

完整的 XML 计划

查询存储：

计划缓存 DMV：

我目前在 Windows 10 上使用最新版本的 SSMS (17.8.1)，每次我尝试创建数据库图表时，它都会崩溃，但不会给我任何错误消息。我已经尝试重新安装SSMS，但问题仍然出现。

我有一个查询应用程序使用文本字段扫描整个表格。

该查询正在执行以下多次读取：

扫描计数 1、逻辑读取 170586、物理读取 3、预读读取 174716、lob 逻辑读取 7902578、lob 物理读取 8743、lob 预读读取 0。

具有 lob 逻辑读取的查询计划

如果我从选择中删除文本字段，则读数将变为以下内容：

扫描计数 1、逻辑读取 170588、物理读取 0、预读读取 0、lob 逻辑读取 0、lob 物理读取 0、lob 预读读取 0。

没有 lob 逻辑读取的查询计划

我不明白的是 lob 读取是如何工作的：

如果我用 lob 逻辑读取来总结逻辑读取，我总共得到8.073.164 逻辑读取，如果我是正确的，大约是 64GB。

但整个数据库只有7GB！

我可能遗漏了一些有关添加逻辑读取和 lob 逻辑读取的信息。

lob 逻辑读取数实际代表什么？

我们计划在这个物理架构上安装一个 SQL Server：

• 基于windows server 2019的hyper-v集群
• 所有虚拟机所在的集群共享卷
• 包含 CSV 的全闪存 SAN

我一直读到，为数据文件、日志文件、临时数据库文件等拥有多个磁盘是一种常见的最佳实践......

但该最佳实践指的是裸机安装。

所以，我要问的是：在上述架构（如果有的话）上这样做的实际好处是什么？