小编sha*_*non的帖子

我有一个有点复杂的 SQL Server 2008 查询（大约 200 行相当密集的 SQL），它没有按照我的需要执行。随着时间的推移，性能从大约 0.5 秒下降到大约 2 秒。

查看执行计划，很明显，通过重新排序连接，可以提高性能。我做到了，它做到了……下降到大约 0.3 秒。现在查询有“OPTION FORCE ORDER”提示，生活很好。

今天我来了，清理数据库。我归档了大约 20% 的行，除了删除行之外，在相关数据库中没有采取任何行动……执行计划完全被控制。它完全错误地判断了某些子树将返回多少行，并且（例如）替换了一个：

<Hash>

和

<NestedLoops Optimized='false' WithUnorderedPrefetch='true'>

现在查询时间从大约 0.3 秒飙升到大约 18 秒。(!) 只是因为我删除了行。如果我删除查询提示，我将回到大约 2 秒的查询时间。更好，但更糟。

将数据库恢复到多个位置和服务器后，我重现了该问题。简单地从每个表中删除大约 20% 的行总是会导致这个问题。

1. 对于强制连接顺序使查询估计完全不准确（因此查询时间不可预测），这是否正常？
2. 我应该只是期望我要么接受次优查询性能，要么像鹰一样观察它并经常手动编辑查询提示？或者也提示每个加入？.3s 到 2s 是一个很大的打击。
3. 为什么优化器在删除行后爆炸很明显？例如，“是的，它进行了样本扫描，并且由于我在数据历史记录中较早地存档了大部分行，样本产生了稀疏结果，因此它低估了对排序散列操作的需求”？

如果您想查看执行计划，请建议我可以发布它们的位置。否则，我已经采样了最令人惊叹的一点。这是基本的错误估计，括号中的数字是（估计：实际）行。

                             /  Clustered Index Scan (908:7229)
Nested Loops (Inner Join) --<
                             \  NonClustered Index Seek (1:7229)

请注意，内循环预期扫描 908 行，但扫描 52,258,441。如果它是准确的，这个分支会运行大约 2 毫秒，而不是 12 秒。在删除行之前，这个内部连接估计值仅相差 2 倍，并且作为两个聚集索引的哈希匹配执行。

我想在 SQL Server 中实现类或表继承（Account、CatAccountDetails、DogAccountDetails）。

我找到了对 MySQL 的推荐：

如何将 IS-A 关系映射到数据库中？

基本上，它是：

• 在父表 (Account) 和子类型表 (CatAccountDetails, DogAccountDetails) 之间使用相同的主键
• 将子类型鉴别器列添加到父表和子类型表
• 在从子类型到父类型表的外键约束中包括共享主键和子类型列

添加一个被限制为单个值的类型列（例如 CatAccountDetails 中的“C”列）感觉有点笨拙，所以我想知道SQL Server 中是否有一个功能可以启用这种情况？

另外，如果这是这样做的方法，我是否应该另外定义一些东西来防止这个“未使用”的列在我的 ORM（实体框架）请求表连接时降低性能，比如只在 PK 上创建一个额外的外键？

主要问题是CatAccountDetails将有不同的列DogAccountDetails。在我的应用程序中，猫与狗相比具有不同且更多的属性。旁注，“猫”和“狗”代表我当前场景中的三类网站成员。

我正在对具有多重性的数据进行建模，如下所示：

每个 Composition/Anthology 相关对必须共享一个 Composer。此外，每本选集必须包含至少一个作品。你会如何推荐我建模这个？

这是一种几乎强制一致性的可能表示（它不强制 1+ Composition : 0+ Anthology 多样性）。然而，它复制了 FK_Composer 很多地方（作为副烦恼破坏了我的一些实体框架功能）。

Composer    Composition    junction          Anthology
--------    -----------    --------------    ---------
                           FK_Anthology   -> PK
PK       <- FK_Composer <- FK_Composer    -> FK_Composer
            PK          <- FK_Composition

注意：我也在尝试在业务逻辑和 ORM 层解决这个问题，并且在那里也遇到了障碍。

• /sf/ask/1139159171/
• /sf/ask/1141908911/