c# - 如何摆脱作为主键的 guid 字段

Question

我陷入了困境，想看看能否摆脱困境。我有一个数据库，其中包含在 uniqueidentifier 列上定义的表上的所有主键。这有点强制我们，将“安全”作为原因之一。另一个我认为比较有值(value)的原因是一些表参与了复制。

我正在审查数据库，我觉得一个很容易避免的 future 性能瓶颈是可以在所有表​​中添加自动增量 bigint 列并使它们成为主键(集群)。并以某种方式正确地“附加” pk-fk 关系。但仍保留旧列以备将来使用。

在这方面有什么建议/意见/建议吗？我们的环境是 c#/MSSQL Server R2/Linq 环境。

编辑: 看着评论，我意识到我遗漏了一些重要的细节。 所有主键 Guid 字段都是集群的，不，我没有使用 newsequentialId(我们使用 Linq to SQL，主键是在客户端生成的。由于涉及复制，我们不确定是否可以从不同的客户端环境正确生成顺序 ID，而无需冲突)。

我的“感觉”是由于众所周知的事实，即 guid 列上的聚簇索引会导致高度碎片化，并且只会随着数据库的增长而使情况恶化。

另外，我现在并不是真的在尝试优化，而是在尝试纠正错误的设计以避免将来数据库变得太大时出现问题。想知道现在是否值得这样做。

有用的讨论也与这里的问题有关 this post ， 和 another

Answer 1

对数据库进行性能调优其实很简单，但也很难。首先，您需要通过在至少一个工作日(但最好是两个工作日)内运行长时间运行的配置文件来收集针对数据库执行的语句列表。

将该配置文件保存到数据库中以便查询，因此您可以轻松找到针对您的数据库执行的 DISTINCT 查询。

在确定执行最多的那些之后，分析它们的执行计划，很可能它与 GUID 的无关和与查询本身一切有关(即它们太糟糕了)或者您需要一个不同的索引。

注意事项:

1. 使用 WHERE 子句严格过滤的 View 。这些都是存储过程或参数化 View 的绝佳候选对象。
2. JOIN 到非常大的表的语句，这些有时 可以成为子查询的良好候选者。这确实取决于执行计划。
3. 出现 多次执行的语句。这通常是一个好兆头，表明应用程序本身并没有很好地管理它往返服务器的频率。我见过会运行相同查询 10 次以上的应用程序。