我在我们的一台 SQL Server 2016 生产服务器上运行 sp_blitz，结果之一是 CPU 的核心数为奇数。详细消息表明这是一个非常糟糕的 NUMA 配置。
如果 SQL Server 2016 检测到超过 8 个内核的物理处理器，它将使用自动软 NUMA。我们的特定服务器有两个插槽，每个插槽有 10 个 CPU。
SQL Server 错误日志中的启动消息表明：
自动软 NUMA 已启用，因为 SQL Server 检测到具有超过 8 个物理内核的硬件 NUMA 节点。
结果，SQL Server 创建了四个逻辑 NUMA 节点，每个节点有 5 个内核。
这是性能问题吗？
我们使用 MAXDOP = 4。
这里的并行性是一个问题吗？
我们定义了一系列配置，其中，在 RESTful API 的驱动下，最终用户可以构建新的修订版本。配置的某些组件可以有多个值；修订涉及具有一对多关系的多个表。
因为配置被运往别处，修订被标记为已部署，并且变得不可变。如果用户想对配置进行更改，他们必须创建一个新修订（可以从现有修订中克隆）。每个配置的一个 修订版可以标记为“当前”；这允许用户随意在过去的修订之间切换，或者通过不选择任何修订来完全禁用配置。当前版本已部署，当将不同版本标记为“当前”时，您将替换已部署的配置。
我们已经准备好了一切来强制部署修订的不变性；当您第一次使用修订作为当前修订时，该deployed列会自动转换为TRUE，并且所有进一步的INSERT,UPDATE和DELETE与修订相关表中部署的修订 ID 匹配的行的操作都将被阻止。
但是，用于公共名称表中的name列的任何值在所有当前配置的所有“当前”修订中都必须是唯一的。我正在尝试找出执行此操作的最佳策略。
如果这是从配置到公共名称的简单一对多关系，则可以通过对name列使用唯一约束来解决。相反，这是一种一对多模式，revision充当桥接表，并将current_revision_id一对多对多关系“折叠”为从配置到虚拟的一对多关系公共名称。
这是一组简化的表格，用于说明我们的情况：
Run Code Online (Sandbox Code Playgroud)-- Configurations CREATE TABLE config ( id INT PRIMARY KEY, name VARCHAR(100), current_revision_id INT ); -- Have multiple revisions CREATE TABLE revision ( id INT PRIMARY KEY, config_id INT NOT NULL REFERENCES config(id), created_at TIMESTAMP WITH TIME ZONE …