行内约束与行外/多列约束的性能及内存差异问询

首先明确核心结论：行内（列级）约束和行外（表级）约束在性能、内存占用上没有本质差异。数据库引擎执行时会将这两类约束视为同等规则，不会因为定义位置不同产生执行效率或内存消耗的区别，二者的差异主要体现在语法写法、报错清晰度和维护灵活性上。

三种约束创建方式的具体分析 #

基于需求（FirstName和LastName非空且各自唯一），以下是三种方式的细节对比：

方式一：列级行内约束

CREATE TABLE Names (
    FirstName VARCHAR(50) NOT NULL UNIQUE CHECK (FirstName IS NOT NULL),
    LastName VARCHAR(50) NOT NULL UNIQUE CHECK (LastName IS NOT NULL)
);

• 语法简洁，直接将约束绑定到对应列上。
• 注意：NOT NULL本身是标准约束，CHECK (FirstName IS NOT NULL)属于冗余定义，数据库会自动忽略这类重复规则。
• 性能/内存：与表级约束完全一致，引擎处理逻辑无区别。

方式二：表级行外约束（逗号分隔）

CREATE TABLE Names (
    FirstName VARCHAR(50),
    LastName VARCHAR(50),
    CONSTRAINT uq_firstname UNIQUE (FirstName),
    CONSTRAINT chk_firstname_notnull CHECK (FirstName IS NOT NULL),
    CONSTRAINT uq_lastname UNIQUE (LastName),
    CONSTRAINT chk_lastname_notnull CHECK (LastName IS NOT NULL)
);

• 这是标准的表级约束定义方式，绝非严重错误——反而更灵活：支持给约束命名（方便后续单独修改、删除约束），也能轻松定义跨多列的复杂约束。
• 性能/内存：与列级约束无差异，针对UNIQUE约束，数据库会自动生成相同的唯一索引，插入、更新时的验证逻辑完全一致。
• 优势：违反约束时会明确提示约束名称，便于快速定位问题，后期维护成本更低。

方式三：合并为多列CHECK约束

CREATE TABLE Names (
    FirstName VARCHAR(50),
    LastName VARCHAR(50),
    CONSTRAINT uq_firstname UNIQUE (FirstName),
    CONSTRAINT uq_lastname UNIQUE (LastName),
    CONSTRAINT chk_names_notnull CHECK (FirstName IS NOT NULL AND LastName IS NOT NULL)
);

• 这里仅将两个非空CHECK约束合并为一个复合约束，UNIQUE约束仍需单独定义（组合唯一键无法实现“各自唯一”的需求）。
• 性能/内存：不会产生额外的性能或内存开销。数据库引擎对单个复合CHECK约束的评估效率，和两个单独CHECK约束基本一致——都是在插入/更新时验证条件，没有本质区别。
• 缺点：违反约束时无法明确提示是FirstName还是LastName为空，只能提示复合约束被触发，增加了开发排查问题的成本，但仅影响体验，不影响性能。

总结 #

1. 约束定义的位置（列级/表级）不影响性能和内存，数据库引擎的处理逻辑完全相同。
2. 方式二是更推荐的约束定义方式，不存在错误，反而在维护性和报错清晰度上更优。
3. 方式三的复合CHECK约束对性能、内存无负面影响，唯一的问题是报错信息不够精准。

内容的提问来源于stack exchange，提问作者Shmiel