在我的数据库中，没有人在补丁和版本之外添加、删除或禁用约束。所有约束均已启用并受信任。定期检查不受信任或禁用的约束，以防意外引入。DBCC CHECKDB还定期运行以检查是否存在腐败。
DBCC CHECKCONSTRAINTS定期跑步有什么好处DBCC CHECKDB吗？还是我造成了不必要的工作？通常应该在什么时候DBCC CHECKCONSTRAINTS运行？
当我们的一些程序尝试使用系统命名的 PK 约束创建临时表时，我们偶尔会遇到错误“数据库中已经有一个名为 'PK__#TempTab__0796211ACE71813B' 的对象”，如下所示：
CREATE OR ALTER PROCEDURE dbo.StoredProc AS
BEGIN
CREATE TABLE #TempTable (id INT NOT NULL, PRIMARY KEY CLUSTERED (id))
...
END
查询 tempdb.sys.objects 会发现数百个 PK__#TempTab__XYZ 形式的约束。许多是几小时前创建的，从那以后就没有被修改过。当我查看 tempdb.sys.objects 时，活动会话非常少，因此很难相信当前有这么多临时表正在使用。我们确实在许多存储过程中创建了许多类似名称的临时表。
我认为临时表缓存在这里负责。这些 PK 约束似乎一直存在于 tempdb 中，直到它们相关的缓存计划被删除。测试表明，禁用临时表缓存（创建统计信息、添加命名约束等）会导致 PK 约束在临时表超出范围时从 tempdb.sys.objects 中删除。触发重新编译和刷新 proc 缓存也会从 tempdb.sys.objects 中清除这些 PK 约束。
我知道系统命名的约束不能保证是唯一的，如本文所述SQL Server 可以在系统生成的约束名称中创建冲突吗？.
我的问题是：
- 我是否错误地认为临时表缓存会增加临时表上系统命名约束的名称冲突的机会？
- 计划缓存膨胀是否会导致我在 tempdb.sys.objects 中看到的大量 PK__#TempTab__XYZ 约束，从而增加两个约束具有相同名称的机会？我试图理解为什么我们经常看到这种罕见的错误。
- 如果我们不能确保临时表上的系统命名约束永远不会遇到命名冲突，我们可以做些什么来减少这些冲突的机会呢？