Postgres 9.x 中 CHECK 约束的成本是多少？答案

【问题标题】：What's the cost of CHECK constraints in Postgres 9.x?Postgres 9.x 中 CHECK 约束的成本是多少？
【发布时间】：2020-08-07 06:03:10
【问题描述】：

我有一张有 60 列的表格。其中 20 个是“NotEmpty”和 6 个“NotNull”。

我有空值和 Null 值（在我的情况下总是意味着“没有数据”）。我想用一种约束来统一列。

我读到空值很便宜（以字节为单位）。所以也许使用 NotEmpty 约束？但也许 NotNull 约束表现更好？或者在检索数据时最好同时拥有这两个值并使用coalesce()？

Postgres 9.x 中 INSERT 和 UPDATE 的 CHECK 约束的成本是多少？你的经历如何？有什么基准吗？

【问题讨论】：

【解决方案1】：

有些人试图避免NULL 值，声称逻辑会令人困惑。

我不是其中之一。 NULL 值适用于没有数据的列。它们当然是存储“空”列的最便宜的方式——对于磁盘空间和性能（主要影响是更小的表和索引）：

一旦您了解NULL 值的本质，就没有理由回避它们。 Postgres 提供了多种函数来处理 NULL。 colaesce(), nullif(), concat(), concat_ws(), ...

一般而言，就性能而言，NOT NULL 约束优于 CHECK 约束，并且都优于触发器强>通过日志拍摄。但即使是简单的触发器也很便宜。 NOT NULL 约束的成本几乎为零。此外，所有这些都只影响写入操作，但在大多数应用程序中，读取操作占主导地位。

因此，对性能最相关的影响（次优索引和查询除外）是表和索引的大小，或者更重要的是每个数据页的元组数强>。对于大多数用例，较大的元组会导致性能下降。为满足查询而必须读取的数据页数相应增加。可用的缓存内存提前饱和。

我没有准备好基准测试，但最好还是针对您的特定环境进行测试。这些只是简单的经验法则。现实要复杂得多。

【讨论】：

我不想逃避 NULLability 但我想统一 NULL 和 EMPTY 之间的数据缺失。我的问题是，就性能而言，最好使用 NULL 并在 EMPTY 上有一个 CHECK CONSTRAINT 或存储 EMPTY 并有一个 NOT NULL CHECK CONSTRAINT？ 从你的链接中，所有有趣的，突出存储与任何其他相比，NULL 的亮度。 与 CHECK 约束 EMPTY 值相比，“NULL 亮度”如何提高性能？这是我解释的问题。