分区列规则

分区列存在于每个成员表上,并且通过 CHECK 约束标识特定表中的可用数据。

 

分区列必须遵守如下规则:

(1) 每个基表都拥有键值由 CHECK 约束所强制的分区列。

(2) 每个表的 CHECK 约束的键范围与其它任何表互不重叠。

(3) 任何分区列的给定值必须只能映射到一个表。

(4) CHECK 约束只能使用以下运算符:BETWEEN、AND、OR、<、<=、>、>=、=。

(5) 分区列不能是标识、默认或 timestamp 列。

(6) 在视图中,分区列必须位于每个 SELECT 语句的选择列表中相同的序号位置处。

      例如,分区列要么总是每个选择列表中的首列,要么总是每个选择列表中的第二列,依次类推。

(7) 分区列不允许为空。

(8) 分区列必须是表的主键的一部分。

(9) 分区列不能是计算列。

(10) 在分区列上必须只有一个约束。如果约束多于一个,SQL Server 会忽略所有的约束并在确

        定视图是否为分区视图时不考虑这些约束。

(11) 分区列的可更新性没有约束。

 

INSERT 语句通过分区视图将数据添加到成员表中。INSERT 语句必须遵守下列规则:

(1) 所有列必须包含在 INSERT 语句中,即使基表中的列可能为 NULL 或在基表中定义了 DEFAULT 约束。

(2) 不能在 INSERT 语句的 VALUES 子句中指定 DEFAULT 关键字。

(3) INSERT 语句提供的值必须符合在一个成员表的分区列上定义的 CHECK 约束逻辑。

(4) 如果一个成员表包含具有标识属性的列,则不能使用 INSERT 语句。

(5) 如果一个成员表包含 timestamp 列,则不能使用 INSERT 语句。

(6) 如果存在具有同一视图或任一成员表的自联接,则不能使用 INSERT 语句。

<think>好的,用户问的是“是否支持虚拟分区”,我需要先理解这个问题。用户之前已经问过是否支持虚拟,现在进一步问是否可以用虚拟作为分区键。根据之前的回答,PostgreSQL不直接支持非存储的虚拟,但有生成、视图、函数索引和触发器等替代方案。 首先,我需要确认PostgreSQL分区功能是否支持使用生成或虚拟作为分区键。记得在之前的回答中提到过生成可以作为分区键,但可能需要具体验证。例如,存储生成是物理存在的,所以理论上可以作为分区键。而虚拟如通过视图或函数索引实现的,可能不被直接支持,因为分区键需要实际存在的。 接下来,我需要查阅PostgreSQL的文档,确认生成是否可以用作分区键。PostgreSQL 12引入了生成,而分区表的支持在后续版本中逐渐增强。可能需要检查是否允许使用生成分区键,或者是否有任何限制。 然后,考虑用户可能的实际应用场景。用户可能希望根据某个动态计算的值来分区数据,比如根据日期范围生成不同的分区,或者根据某个计算字段进行哈希分区。使用生成作为分区键可以满足这种需求,但需要确保生成的计算是确定性的,并且符合分区的要求。 另外,用户可能遇到的问题包括生成是否支持分区、如何创建这样的分区表、性能如何,以及维护上的注意事项。需要详细说明步骤,并提供示例代码,比如创建生成,然后基于该创建范围分区分区。 还需要考虑替代方案,例如使用常规结合触发器来维护分区键的值,或者使用函数索引和分区表达式。这可能涉及到使用表达式分区,即在分区时直接使用一个表达式而不是单独的,但需要PostgreSQL版本支持。 最后,总结不同方法的优缺点,帮助用户选择最适合的方案,并提出相关问题,如生成作为分区键的性能影响、维护注意事项等,确保用户全面了解各种可能性。</think>PostgreSQL **支持使用生成(Generated Columns)作为分区键**,但需注意以下限制和实现方式: --- ### 1. 存储生成(STORED)作为分区键 ```sql -- 示例:创建基于生成的范围分区表 CREATE TABLE sales ( id SERIAL, sale_date DATE NOT NULL, amount NUMERIC(10,2) NOT NULL, sale_year INT GENERATED ALWAYS AS (EXTRACT(YEAR FROM sale_date)) STORED ) PARTITION OF base_sales PARTITION BY RANGE (sale_year); -- 使用生成作为分区键 -- 创建具体分区 CREATE TABLE sales_2023 PARTITION OF sales FOR VALUES FROM (2023) TO (2024); ``` **特性**: - 生成必须为 `STORED` 类型(虚拟不支持) - 分区键必须为确定性计算(如日期提取、数学运算) - 支持范围(RANGE)、表(LIST)、哈希(HASH)分区 --- ### 2. 虚拟替代方案(非存储) 若需使用虚拟逻辑,可通过以下方式间接实现: #### (1) 表达式分区(Expression-based Partitioning) ```sql -- 直接使用表达式作为分区键 CREATE TABLE sales ( id SERIAL, sale_date DATE NOT NULL, amount NUMERIC(10,2) NOT NULL ) PARTITION BY RANGE (EXTRACT(YEAR FROM sale_date)); -- 创建具体分区 CREATE TABLE sales_2023 PARTITION OF sales FOR VALUES FROM (2023) TO (2024); ``` **优势**: - 无需物理存储计算 - 分区键表达式可动态调整 --- ### 3. 版本兼容性 | PostgreSQL版本 | 生成支持 | 表达式分区支持 | |----------------|------------|----------------| | 10 | ❌ | ❌ | | 12 | ✅(仅存储) | ✅ | | 13+ | ✅ | ✅ | --- ### 4. 性能与维护 - **写入性能**:生成增加写入时计算开销(如 `EXTRACT(YEAR FROM date)`) - **分区维护**:需定期清理过期分区(如使用 `pg_partman` 扩展) - **索引优化**:对生成创建索引可加速分区裁剪(Partition Pruning) --- ### 5. 典型场景对比 | 方案 | 存储开销 | 分区灵活性 | 适用场景 | |---------------------|----------|------------|------------------------------| | 存储生成+分区 | 高 | 中 | 固定规则分区(如按年) | | 表达式分区 | 无 | 高 | 动态规则分区(如哈希分片) | | 视图+手动分区 | 低 | 低 | 复杂业务逻辑(需自定义代码) | --- ### 示例:哈希分区与生成 ```sql -- 创建哈希分区表(基于生成) CREATE TABLE user_logins ( user_id INT, login_time TIMESTAMP, hash_key INT GENERATED ALWAYS AS (user_id % 4) STORED ) PARTITION BY HASH (hash_key); -- 创建4个哈希分区 CREATE TABLE user_logins_0 PARTITION OF user_logins FOR VALUES WITH MODULUS 4 AND REMAINDER 0; -- ...重复创建余数1~3的分区 ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值