华为云用户手册

RCR UBTree多版本管理 RCR(Row Consistency Read) UBtree的多版本管理是基于数据行的行级多版本管理，将XID记录在了数据行上，会增加Key的大小，索引会有5-20%左右的膨胀。最新版本和历史版本均在btree上，索引没有记录Undo信息。插入或者删除key时按照key + TID的顺序排列，索引列相同的元组按照对应元组的TID作为第二关键字进行排序。会将xmin、xmax追加到key的后面。索引分裂时，多版本信息随着key的迁移而迁移，如图1所示。 图1 RCR UBTree多版本管理

RCR UBTree空间管理 当前Astore的索引依赖AutoVacuum和Free Space Map（FSM）进行空间管理，存在回收不及时的问题。而Ustore的索引使用其特有的URQ（UBTree Recycle Queue，一种基于循环队列的数据结构，即双循环队列），对索引空闲空间进行管理。双循环队列是指有两个循环队列，一个潜在空页队列，另一个可用空页队列，在DML过程中完成索引的空间管理，能有效地缓解DML过程中造成的空间急剧膨胀问题。索引回收队列单独储存在BTree索引对应的FSM文件中。 图5 索引页面在双循环队列间流动 如图5所示，索引页面在双循环队列间流动如下： 索引空页流动到潜在队列 索引页尾字段中记录了页面上活跃元组个数（activeTupleCount），在DML过程中，删空一个页面的所有元组，即activeTupleCount为零时会将索引页放入潜在队列中。 潜在队列流动到可用队列 潜在队列到可用队列的转化主要是达到一个潜在队列收支平衡以及可用队列在拿页时有页可拿的目的，即当从可用队列拿出一个索引空页用完后，建议从潜在队列转化至少一个索引页面到可用队列中，以及每当潜在队列新加入一个索引页面时，能从潜在队列中移除至少一个索引页插入可用队列中，达到潜在队列的收支平衡，以及可用队列有页可用的目的。 可用队列流动到索引空页 索引在分裂等获取一个索引空页面时，会先从可用队列中进行查找是否有可以复用的索引页。如果找到则直接进行复用，没有可复用页面则进行物理扩页。

RCR UBTree增删改查 Insert操作：UBTree的插入逻辑基本不变，只需增加索引插入时直接获取事务信息填写xmin字段。 Delete操作：UBTree额外增加了索引删除流程，索引删除主要步骤与插入相似，获取事务信息填写xmax字段（BTree索引不维护版本信息，不需要删除操作）,同时更新页面上的active_tuple_count，若active_tuple_count被减为0，则尝试页面回收。 Update操作：对于Ustore而言，数据更新对UBTree索引列的操作也与Astore有所不同，数据更新包含两种情况：索引列和非索引列更新，UBTree在数据发生更新时的处理如图3所示。 图3 UBTree在数据发生更新时的处理 图3展示UBTree在索引列和非索引列更新的差异： 在非索引列更新的情况下，索引不发生任何变化。index tuple仍指向第一次插入的data tuple，Uheap不会插入新的data tuple，而是修改当下data tuple并将历史数据存入Undo中。 在索引列更新的情况下，UBTree也会插入新的index tuple，但是会指向同一个data linepointer和同一个data tuple，扫描旧版本的数据则需要从Undo中读取。 Scan操作：用户在读取数据时，可通过使用索引扫描加速。UBTree支持索引数据的多版本管理及可见性检查，索引层的可见性检查使得索引扫描（Index Scan）及仅索引扫描（IndexOnly Scan）性能有所提升。 对于索引扫描： 若索引列包含所有扫描列（IndexOnly Scan），则通过扫描条件在索引上进行二分查找，找到符合条件元组即可返回数据。 若索引列不包含所有扫描列（Index Scan），则通过扫描条件在索引上进行二分查找，找到符合条件元组的TID，再通过TID到数据表上查找对应的数据元组。如图4所示。 图4 对应的数据元组

RCR Uheap空闲空间管理 Ustore使用Free Space Map（FSM）文件记录了每个数据页的潜在空闲空间，并且以树的结构组织起来。每当用户想要对某个表执行插入操作或者是非原位更新操作时，就会从该表对应的FSM中进行快速查找，查看当前FSM上记录的最大空闲空间是否可以满足插入所需的空间要求。如果满足则返回对应的blocknum用于执行插入操作，否则执行拓展页面逻辑。 每一个表或者分区对应的FSM结构存放在一个独立的FSM文件中，该FSM文件与表数据放在相同的目录下。例如，假设表t1对应的数据文件为32181，则其对应的FSM文件为32181_fsm。FSM内部同样是以数据块的格式存储，这里称为FSM block，FSM block之间的逻辑结构组成了一棵有三层节点的树，树的节点在逻辑上是大顶堆关系。每次在FSM上查找时从根节点进行，一直查找到叶子节点，然后在叶子节点内搜索到一个可用的页面并返回给业务用于执行后续操作。 该结构不保证和数据页实际可用空间保持实时一致，会在DML的执行过程中进行维护。Ustore会在Auto Vacuum的过程中概率性对该FSM进行修复重建。当用户执行插入类型的DML语句，类似Insert/Non-Inplace Update(新页面)/Multi Insert时，会查询FSM结构，寻找到一个可以插入当前记录的空间。用户执行完DML操作后会根据当前页面的潜在空闲空间与实际空闲空间的差值来决定是否将该页面的空闲空间刷新到FSM上。该差值越大，即潜在空间大于实际空间越多，则该页面被更新至FSM的几率越大。FSM上会记录数据页的潜在空闲空间 ，在用户执行插入操作找到一个页面时，如果该页面上的空闲空间较大则直接插入，否则如果潜在空间较大则对页面执行清理后插入，最后如果空间不够则重新搜索FSM结构或者拓展总页面数量。更新FSM结构主要有以下几个位置，DML、页面清理、vacuum、拓展页面、分区合并、页面扫描等。 父主题： RCR Uheap

RCR Uheap多版本管理 Ustore对其使用的heap做了如下重要的增强，简称Uheap。 Ustore RCR(Row Consistency Read)的多版本管理是基于数据行的行级多版本管理，不过Ustore将XID记录在了页面的TD(Transaction Directory)区域，区别于常见的将XID存储在数据行上，节省了页面空间。事务修改记录时，会将历史数据记录到Undo Row中，在Tuple中的td_id指向的TD槽上记录产生的Undo Row地址(zone_id, block no, page offset)，并将新的数据覆盖写入页面。访问元组时，沿着版本链还原该元组，直到找到自己对应的版本。 父主题： RCR Uheap

在线校验功能 在线校验是Ustore特有的，在运行过程中可以有效预防页面因编码逻辑错误导致的逻辑损坏，默认开启UPAGE:UBTREE:UNDO三个模块校验。业务现网请保持开启，性能场景除外。 关闭： gs_guc reload -Z datanode -N all -I all -c "ustore_attr=''" 打开： gs_guc reload -Z datanode -N all -I all -c "ustore_attr='ustore_verify_level=fast;ustore_verify_module=upage:ubtree:undo'" 父主题： Ustore的最佳实践

使用Ustore进行测试 创建Ustore表 使用CREATE TABLE语句创建Ustore表。 gaussdb=# CREATE TABLE ustore_table(a INT PRIMARY KEY, b CHAR (20)) WITH (STORAGE_TYPE=USTORE); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "ustore_table_pkey" for table "ustore_table" CREATE TABLE gaussdb=# \d+ ustore_table Table "public.ustore_table" Column | Type | Modifiers | Storage | Stats target | Description --------+---------------+-----------+----------+--------------+------------- a | integer | not null | plain | | b | character(20) | | extended | | Indexes: "ustore_table_pkey" PRIMARY KEY, ubtree (a) WITH (storage_type=USTORE) TABLESPACE pg_default Has OIDs: no Options: orientation=row, storage_type=ustore, compression=no, segment=off 删除Ustore表 gaussdb=# DROP TABLE ustore_table; DROP TABLE 为Ustore表创建索引 Ustore当前仅支持BTree类型的多版本索引。在一些场景中，为了区别于Astore的BTree索引，也会将Ustore表的多版本BTree索引称为UBTree（Ustore BTree，UBTree介绍详见UBTree章节）。用户可以参照以下方式使用CREATE INDEX语句为Ustore表的“a”属性创建一个UBTree索引。 Ustore表不指定创建索引类型，默认创建的是UBTree索引。 UBTree索引分为RCR版本和PCR版本，默认创建RCR版本的UBTree。若在创建索引时，with选项指定(index_txntype=pcr)或者指定GUC的index_txntype=pcr，则创建的是PCR版本的UBTree。 gaussdb=# CREATE TABLE test(a int); CREATE TABLE gaussdb=# CREATE INDEX UB_tree_index ON test(a); CREATE INDEX gaussdb=# \d+ test Table "public.test" Column | Type | Modifiers | Storage | Stats target | Description --------+---------+-----------+---------+--------------+------------- a | integer | | plain | | Indexes: "ub_tree_index" ubtree (a) WITH (storage_type=USTORE) TABLESPACE pg_default Has OIDs: no Options: orientation=row, compression=no, storage_type=USTORE, segment=off --删除Ustore表索引。 gaussdb=# DROP TABLE test; DROP TABLE 父主题： Ustore简介

存储规格 数据表最大列数不能超过1600列。 init_td（TD（Transaction Directory，事务目录）是Ustore表独有的用于存储页面事务信息的结构，TD的数量决定该页面支持的最大并发数。在创建表或索引时可以指定初始的TD大小init_td）取值范围[2, 128]，默认值4。单页面支持的最大并发不超过128个。 Ustore表（不含toast情况）最大Tuple长度不能超过（8192 - MAXALIGN(56 + init_td * 26 + 4)），其中MAXALIGN表示8字节对齐。当插入数据长度超过阈值时，用户会收到元组长度过长无法插入的报错。其中init_td对于Tuple长度的影响如下： 表init_td数量为最小值2时，Tuple长度不能超过8192 - MAXALIGN(56+2*26+4) = 8080B。 表init_td数量为默认值4时，Tuple长度不能超过8192 - MAXALIGN(56+4*26+4) = 8024B。 表init_td数量为最大值128时，Tuple长度不能超过8192 - MAXALIGN(56+128*26+4) = 4800B。 索引最大列数不能超过32列。全局分区索引最大列数不能超过31列。 索引元组长度不能超过(8192 - MAXALIGN(28 + 3 * 4 + 3 * 10) - MAXALIGN(42))/3，其中MAXALIGN表示8字节对齐。当插入数据长度超过阈值时，用户会收到索引元组长度过长无法插入的报错，其中索引页头为28B，行指针为4B，元组CTID+INFO标记位为10B，页尾为42B。 回滚段容量最大支持16TB。 父主题： Ustore特性与规格

使用Ustore的优势 最新版本和历史版本分离存储，相比Astore扫描范围小。去除Astore的HOT chain，非索引列/索引列更新，Heap均可原位更新，ROWID可保持不变。历史版本可批量回收，空间膨胀可控。 B-tree索引增加了事务信息，能够独立进行MVCC。增加了IndexOnlyScan的比例，大大减少回表次数。 不依赖Vacuum进行旧版本清理。独立的空间回收能力，索引与堆表解耦，可独立清理，I/O平稳度更优。 大并发更新同一行的场景，相对于Astore的ROWID会偏移，Ustore的原位更新机制保证了元组ROWID稳定，先到先得，更新时延相对稳定。 支持闪回功能。 Ustore DML在修改数据页面时，也需要同步生成Undo，因此更新操作开销会稍大一些。此外单条Tuple扫描开销由于需要复制（Astore返回指针）也会大一些。

使用Astore的优势 Astore没有回滚段，而Ustore有回滚段。对于Ustore来说，回滚段是非常重要的，回滚段损坏会导致数据丢失甚至数据库无法启动的严重问题。且Ustore恢复时同步需要Redo和Undo。由于Astore没有回滚段，旧数据都是记录在原先的文件中，所以当数据库异常crash后，恢复时不会像Ustore数据库那样进行复杂的恢复。 由于旧的数据是直接记录在数据文件中，而不是回滚段中，所以不会经常报Snapshot Too Old错误。 回滚可以很快完成，因为回滚并不删除数据。 回滚时很复杂，在事务回滚时必须清理该事务所进行的修改，插入的记录要删除，更新的记录要更新回来，同时回滚的过程也会再次产生大量的Redo日志。 WAL日志要简单一些，仅需要记录数据文件的变化，不需要记录回滚段的变化。 支持回收站（闪回DROP、闪回Truncate）功能。

GaussDB 内核R2版本 Ustore增加新的基于原位更新的行存储引擎Ustore，首次实现新、旧版本记录的分离存储。 Ustore增加回滚段模块。 Ustore增加回滚过程，支持同步/异步/页内模式。 Ustore增加支持事务的增强版本B-tree。 Astore增加闪回功能，支持闪回表/闪回查询/闪回Drop/闪回Truncate。 Ustore不支持的特性包括分布式并行查询/Table Sampling/Global Temp Table/在线创建/重建索引/极致RTO/Vacuum Full/列约束DEFERRABLE以及INITIALLY DEFERRED。 父主题： 存储引擎更新说明

GaussDB内核503版本 Ustore适配分布式/并行查询/Global Temp Table/Vacuum full/列约束DEFERRABLE以及INITIALLY DEFERRED。 Ustore增加在线重建索引。 Ustore增加增强版本B-tree空页面估算，提升优化器代价估算准确度。 Ustore增加存储引擎可靠性验证框架，Diagnose Page/Page Verify。 Ustore增强存储引擎相关的解析/检测/修复视图。 Ustore增强基于WAL日志的定位能力，新增gs_redo_upage系统视图，支持对单页面的不断重放，获取并打印该页面的任何一个历史版本，加速页面损坏类问题的定位。 Ustore扩展事务槽TD物理格式，为事务内空间复用做好铺垫。 Ustore增加在线创建索引。 Ustore适配闪回功能（for Ustore）/极致RTO。 父主题： 存储引擎更新说明

设置存储引擎 存储引擎会对数据库整体效率和性能存在巨大影响，请根据实际需求选择适当的存储引擎。用户可使用WITH ( [ORIENTATION | STORAGE_TYPE] [= value] [, ... ] )为表或索引指定一个可选的存储参数。参数的详细描述如下所示： ORIENTATION STORAGE_TYPE ROW（缺省值）：表的数据将以行式存储。 [USTORE(缺省值)|ASTORE|空] 如果ORIENTATION指定为ROW，且STORAGE_TYPE为空的情况下创建出的表类型取决于GUC参数enable_default_ustore_table（取值为on/off，默认情况为on）：如果参数设置为on，创建出的表为Ustore类型；如果为off，创建出的表为Astore类型。 具体示例如下： gaussdb=# CREATE TABLE TEST(a int); gaussdb=# \d+ test Table "public.test" Column | Type | Modifiers | Storage | Stats target | Description --------+---------+-----------+---------+--------------+------------- a | integer | | plain | | Has OIDs: no Options: orientation=row, compression=no, storage_type=USTORE, segment=off gaussdb=# CREATE TABLE TEST1(a int) with(orientation=row, storage_type=ustore); gaussdb=# \d+ test1 Table "public.test1" Column | Type | Modifiers | Storage | Stats target | Description --------+---------+-----------+---------+--------------+------------- a | integer | | plain | | Has OIDs: no Options: orientation=row, storage_type=ustore, compression=no, segment=off gaussdb=# CREATE TABLE TEST2(a int) with(orientation=row, storage_type=astore); gaussdb=# \d+ test2 Table "public.test2" Column | Type | Modifiers | Storage | Stats target | Description --------+---------+-----------+---------+--------------+------------- a | integer | | plain | | Has OIDs: no Options: orientation=row, storage_type=astore, compression=no gaussdb=# CREATE TABLE test4(a int) with(orientation=row); gaussdb=# \d+ List of relations Schema | Name | Type | Owner | Size | Storage | Description --------+-------+-------+-----------+---------+------------------------------------------------------------------+------------- public | test | table | z7ee88f3a | 0 bytes | {orientation=row,compression=no,storage_type=USTORE,segment=off} | public | test1 | table | z7ee88f3a | 0 bytes | {orientation=row,storage_type=ustore,compression=no,segment=off} | public | test2 | table | z7ee88f3a | 0 bytes | {orientation=row,storage_type=astore,compression=no} | public | test3 | table | z7ee88f3a | 16 kB | {orientation=column,storage_type=astore,compression=low} | public | test4 | table | z7ee88f3a | 0 bytes | {orientation=row,compression=no,storage_type=USTORE,segment=off} | (5 rows) gaussdb=# show enable_default_ustore_table; enable_default_ustore_table ----------------------------- on (1 row) gaussdb=# DROP TABLE test; gaussdb=# DROP TABLE test1; gaussdb=# DROP TABLE test2; gaussdb=# DROP TABLE test4; 父主题： 存储引擎体系架构

通用数据库服务层 从技术角度来看，存储引擎需要一些基础架构组件，主要包括： 并发：不同存储引擎选择正确的锁可以减少开销，从而提高整体性能。此外提供多版本并发控制或“快照”读取等功能。 事务：均需满足ACID的要求，提供事务状态查询等功能。 内存缓存：不同存储引擎在访问索引和数据时一般会对其进行缓存。缓存池允许直接从内存中处理经常使用的数据，从而加快了处理速度。 检查点：不同存储引擎一般都支持增量checkpoint/double write或全量checkpoint/full page write模式。应用可以根据不同条件进行选择增量或者全量，这个对存储引擎是透明的。 日志：GaussDB采用的是物理日志，其写入/传输/回放对存储引擎透明。 父主题： 存储引擎体系架构概述

静态编译架构 从整个数据库服务的组成架构来看，存储引擎向上对接SQL引擎，为SQL引擎提供或接收标准化的数据格式（元组或向量数组）。向下对接存储介质，按照特定的数据组织方式，以页面、压缩单元（Compress Unit）或其他形式为单位，通过存储介质提供的特定接口，对存储介质中的数据完成读写操作。GaussDB通过静态编译使数据库专业人员可以为特定的应用程序需求选择专用的存储引擎。为了减少对执行引擎的干扰，提供行存访问接口层TableAM，用来屏蔽底层行存引擎带来的差异，使得不同行存引擎可以分别独立演进，如图1所示。 图1 静态编译架构 在此基础之上，存储引擎通过日志系统提供数据的持久化和可靠性能力。通过并发控制（事务）系统保证同时执行的多个读写操作之间的原子性、一致性和隔离性，通过索引系统提供对特定数据的加速寻址和查询能力，通过主备复制系统提供整个数据库服务的高可用能力。 行存引擎主要面向OLTP（OnLine Transaction Processing）类业务应用场景，适合高并发、小数据量的单点或小范围数据读写操作。行存引擎向上为SQL引擎提供元组形式的读写接口，向下以页面为单位通过可扩展的介质管理器对存储介质进行读写操作，并通过页面粒度的共享缓冲区来优化读写操作的效率。对于读写并发操作，采用多版本并发控制（MVCC、Multi-Version Concurrency Control）；对于写并发操作，采用基于两阶段锁协议（2PL、Two-Phase Locking）的悲观并发控制（PCC、Pessimistic Concurrency Control）。当前，行存引擎默认的介质管理器采用磁盘文件系统接口，后续可扩展支持块设备等其他类型的存储介质。GaussDB行存引擎可以选择基于Append update的Astore或基于In-place update的Ustore。 父主题： 存储引擎体系架构概述

工具函数示例 pg_get_tabledef获取分区表的定义，入参可以为表的OID或者表名。 SELECT pg_get_tabledef('test_range_pt'); pg_get_tabledef ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- SET search_path = public; + CREATE TABLE test_range_pt ( + a integer, + b integer, + c integer + ) + WITH (orientation=row, compression=no, storage_type=USTORE, segment=off) + PARTITION BY RANGE (a) + ( + PARTITION p1 VALUES LESS THAN (2000) TABLESPACE pg_default, + PARTITION p2 VALUES LESS THAN (3000) TABLESPACE pg_default, + PARTITION p3 VALUES LESS THAN (4000) TABLESPACE pg_default, + PARTITION p4 VALUES LESS THAN (5000) TABLESPACE pg_default, + PARTITION p5 VALUES LESS THAN (MAXVALUE) TABLESPACE pg_default + ) + ENABLE ROW MOVEMENT; + CREATE INDEX idx_range_a ON test_range_pt USING ubtree (a) LOCAL(PARTITION p1_a_idx, PARTITION p2_a_idx, PARTITION p3_a_idx, PARTITION p4_a_idx, PARTITION p5_a_idx) WITH (storage_type=USTORE) TABLESPACE pg_default; (1 row) pg_stat_get_partition_tuples_hot_updated返回给定分区id的分区热更新元组数的统计。 在分区p1中插入10条数据并更新，统计分区p1的热更新元组数。 INSERT INTO test_range_pt VALUES(generate_series(1,10),1,1); INSERT 0 10 SELECT pg_stat_get_partition_tuples_hot_updated(49294); pg_stat_get_partition_tuples_hot_updated ------------------------------------------ 0 (1 row) UPDATE test_range_pt SET b = 2; UPDATE 10 SELECT pg_stat_get_partition_tuples_hot_updated(49294); pg_stat_get_partition_tuples_hot_updated ------------------------------------------ 10 (1 row)

前置建表相关信息 前置建表： CREATE TABLE test_range_pt (a INT, b INT, c INT) PARTITION BY RANGE (a) ( PARTITION p1 VALUES LESS THAN (2000), PARTITION p2 VALUES LESS THAN (3000), PARTITION p3 VALUES LESS THAN (4000), PARTITION p4 VALUES LESS THAN (5000), PARTITION p5 VALUES LESS THAN (MAXVALUE) )ENABLE ROW MOVEMENT; 查看分区表OID： SELECT oid FROM pg_class WHERE relname = 'test_range_pt'; oid ------- 49290 (1 row) 查看分区信息： SELECT oid,relname,parttype,parentid,boundaries FROM pg_partition WHERE parentid = 49290; oid | relname | parttype | parentid | boundaries -------+---------------+----------+----------+------------ 49293 | test_range_pt | r | 49290 | 49294 | p1 | p | 49290 | {2000} 49295 | p2 | p | 49290 | {3000} 49296 | p3 | p | 49290 | {4000} 49297 | p4 | p | 49290 | {5000} 49298 | p5 | p | 49290 | {NULL} (6 rows) 创建索引： CREATE INDEX idx_range_a ON test_range_pt(a) LOCAL; CREATE INDEX --查看分区索引oid SELECT oid FROM pg_class WHERE relname = 'idx_range_a'; oid ------- 90250 (1 row) 查看索引分区信息： SELECT oid,relname,parttype,parentid,boundaries,indextblid FROM pg_partition WHERE parentid = 90250; oid | relname | parttype | parentid | boundaries | indextblid -------+----------+----------+----------+------------+------------ 90255 | p5_a_idx | x | 90250 | | 49298 90254 | p4_a_idx | x | 90250 | | 49297 90253 | p3_a_idx | x | 90250 | | 49296 90252 | p2_a_idx | x | 90250 | | 49295 90251 | p1_a_idx | x | 90250 | | 49294 (5 rows)

DQL/DML-DDL同分区并发 GaussDB不支持同分区的DQL/DML-DDL并发，后触发业务会被先触发业务阻塞。 原则上，不建议用户在进行分区DDL时，同时对该分区进行DQL/DML操作，因为目标分区存在一个状态的突变过程，可能会导致业务的查询结果不符合预期。 如果由于业务模型不合理、无法剪枝等场景导致的DQL/DML和DDL作用分区有重叠时，考虑两种场景： 场景一：先触发DQL/DML，再触发DDL。DDL会被阻塞，等DQL/DML提交后再进行。 场景二：先触发DDL，再触发DQL/DML。DQL/DML会被阻塞，等DDL提交后再进行，由于分区元信息发生了变更，可能导致预期不合理。为了保证数据一致性，预期结果按照如下规则制定。 ADD分区 ADD分区会产生一个新的分区，这个新分区对期间触发的DQL/DML操作均是不可见的，无阻塞期。 DROP分区 DROP分区会将已有分区进行删除，期间触发的目标分区DQL/DML操作会被阻塞，阻塞完成后跳过对该分区的处理。 TRUNCATE分区 TRUNCATE分区会将已有分区清空数据，期间触发的目标分区DQL/DML操作会被阻塞，阻塞完成后继续对该分区进行处理。 注意期间触发的目标分区查询是查不到数据的，因为TRUNCATE操作提交后目标分区中不存有任何数据。 EXCHANGE分区 EXCHANGE分区会将一个已有分区与普通表进行交换，期间触发的目标分区DQL/DML操作会被阻塞，阻塞完成后继续对该分区进行处理，该分区的实际数据对应原普通表。 例外：如果分区表上存在GLOBAL索引，EXCHANGE命令带来UPDATE GLOBAL INDEX子句，且期间触发的分区表查询使用了GLOBAL索引，由于无法查询到交换后分区上的数据，在阻塞完成后查询业务会报错。 ERROR: partition xxxxxx does not exist on relation "xxxxxx" DETAIL: this partition may have already been dropped by cocurrent DDL operations EXCHANGE PARTITION SPLIT分区 SPLIT分区会将一个分区分割为多个分区，即使其中一个新分区与旧分区名字相同，也视为不同的分区。期间触发的目标分区DQL/DML操作会被阻塞。如果SPLIT的源分区不是一个空分区，则阻塞完成后业务报错。 ERROR: partition xxxxxx does not exist on relation "xxxxxx" DETAIL: this partition may have already been dropped by cocurrent DDL operations SPLIT PARTITION MERGE分区 MERGE分区会将多个分区合并为一个分区，如果合并后的分区与其中一个旧分区A名字相同，逻辑上视为相同分区。期间触发的目标分区DQL/DML操作会被阻塞，阻塞完成后，根据目标分区类型判断，如果目标分区是旧分区A，则作用于新分区；如果目标分区为其他旧分区，且不是一个空分区，则业务报错。 ERROR: partition xxxxxx does not exist on relation "xxxxxx" DETAIL: this partition may have already been dropped by cocurrent DDL operations MERGE PARTITION RENAME分区 RENAME分区不会变更分区结构信息，期间触发的DQL/DML操作不会出现任何异常，但会被阻塞，直到RENAME操作提交。 MOVE分区 MOVE分区不会变更分区结构信息，期间触发的DQL/DML操作不会出现任何异常，但会被阻塞，直到MOVE操作提交。 在DQL/DML业务期间，如果对执行DQL/DML操作的分区，连续同时做多次分区DDL操作，有低概率出现报错，报错原因：分区找不到，分区已经被DDL删除。

常规锁设计 分区表通过表锁+分区锁两重设计，在表和分区上分别施加8个不同级别的常规锁，来保证DQL、DML、DDL并发过程中的合理行为控制。下表给出了不同级别锁的相容行为，标记为√的两种常规锁互不阻塞，可以并行。 表1 常规锁相容行为 - AC CES S_SHARE ROW_SHARE ROW_EXCLUSIVE SHARE_UPDATE_EXCLUSIVE SHARE SHARE_ROW_EXCLUSIVE EXCLUSIVE ACCESS_EXCLUSIVE ACCESS_SHARE √ √ √ √ √ √ √ × ROW_SHARE √ √ √ √ √ √ × × ROW_EXCLUSIVE √ √ √ √ × × × × SHARE_UPDATE_EXCLUSIVE √ √ √ × × × × × SHARE √ √ × × √ × × × SHARE_ROW_EXCLUSIVE √ √ × × × × × × EXCLUSIVE √ × × × × × × × ACCESS_EXCLUSIVE × × × × × × × × 分区表的不同业务最终都是作用于目标分区上，数据库会给分区表和目标分区施加不同级别的表锁+分区锁，来控制并发行为。表2给出了不同业务的锁粒度控制。其中数字1~8分别代表表1给出的ACCESS_SHARE、ROW_SHARE、ROW_EXCLUSIVE、SHARE_UPDATE_EXCLUSIVE、SHARE、SHARE_ROW_EXCLUSIVE、EXCLUSIVE、ACCESS_EXCLUSIVE这8种级别的常规锁。 表2 分区表业务锁粒度 业务模型 一级分区表锁级别(表锁+分区锁) 二级分区表锁级别(表锁+一级分区锁+二级分区锁) SELECT 1-1 1-1-1 SELECT FOR UPDATE 2-2 2-2-2 DML业务，包括INSERT、UPDATE、DELETE、UPSERT、MERGE INTO、COPY 3-3 3-3-3 分区DDL，包括ADD、DROP、EXCHANGE、TRUNCATE、SPLIT、MERGE、MOVE、RENAME；打开/关闭分区自动扩展 4-8 4-8-8（作用二级分区表的一级分区） 4-4-8 （作用二级分区表的二级分区） CREATE INDEX（非分类索引）、REBUILD INDEX 5-5 5-5-5 CREATE INDEX（分类索引） 3-5 3-3-5 REBUILD INDEX PARTITION 1-5 1-5-5 ANALYZE、VACUUM 4-4 4-4-4 其他分区表DDL 8-8 8-8-8 如果业务执行施加的表锁和分区锁均满足表1，则可以支持业务并行操作，如果表锁和分区锁有任一不相容，则二者不支持业务并行。 父主题： 分区并发控制

Local索引分区重建/不可用 使用ALTER INDEX PARTITION可以设置Local索引分区是否可用。 使用ALTER TABLE MODIFY PARTITION可以设置分区表上指定分区的所有索引分区是否可用。这个语法如果作用于二级分区表的一级分区，数据库会将这个一级分区下的所有二级分区均进行设置。 使用ALTER TABLE MODIFY SUBPARTITION可以设置二级分区表上指定二级分区的所有索引分区是否可用。 例如，假设分区表range_sales上存在两张Local索引range_sales_idx1和range_sales_idx2，假设其在分区date_202001上对应的索引分区名分别为range_sales_idx1_part1和range_sales_idx2_part1。 下面给出了维护分区表分区索引的语法： 可以通过如下命令设置分区date_202001上的所有索引分区均不可用。 ALTER TABLE range_sales MODIFY PARTITION date_202001 UNUSABLE LOCAL INDEXES; 或者通过如下命令单独设置分区date_202001上的索引分区range_sales_idx1_part1不可用。 ALTER INDEX range_sales_idx1 MODIFY PARTITION range_sales_idx1_part1 UNUSABLE; 可以通过如下命令重建分区date_202001上的所有索引分区。 ALTER TABLE range_sales MODIFY PARTITION date_202001 REBUILD UNUSABLE LOCAL INDEXES; 或者通过如下命令单独重建分区date_202001上的索引分区range_sales_idx1_part1。 ALTER INDEX range_sales_idx1 REBUILD PARTITION range_sales_idx1_part1; 假设二级分区表list_range_sales上存在两张Local索引list_range_sales_idx1和list_range_sales_idx2，表下有一级分区channel1，其下属二级分区有channel1_product1、channel1_product2、channel1_product3，二级分区channel1_product1上对应的索引分区名分别为channel1_product1_idx1和channel1_product1_idx2。 下面给出了维护二级分区表一级分区索引的语法： 可以通过如下命令设置分区channel1下属二级分区的所有索引分区均不可用，包括二级分区channel1_product1、channel1_product2、channel1_product3。 ALTER TABLE list_range_sales MODIFY PARTITION channel1 UNUSABLE LOCAL INDEXES; 可以通过如下命令重建分区channel1下属二级分区的所有索引分区。 ALTER TABLE list_range_sales MODIFY PARTITION channel1 REBUILD UNUSABLE LOCAL INDEXES; 下面给出了维护二级分区表二级分区索引的语法： 可以通过如下命令单独设置二级分区channel1_product1上的所有索引分区均不可用。 ALTER TABLE list_range_sales MODIFY SUBPARTITION channel1_product1 UNUSABLE LOCAL INDEXES; 可以通过如下命令重建二级分区channel1_product1上的所有索引分区。 ALTER TABLE list_range_sales MODIFY SUBPARTITION channel1_product1 REBUILD UNUSABLE LOCAL INDEXES; 或者通过如下命令单独设置二级分区channel1_product1上的索引分区channel1_product1_idx1不可用。 ALTER INDEX list_range_sales_idx1 MODIFY PARTITION channel1_product1_idx1 UNUSABLE; 通过如下命令单独重建二级分区channel1_product1上的索引分区channel1_product1_idx1。 ALTER INDEX list_range_sales_idx1 REBUILD PARTITION channel1_product1_idx1; 父主题： 分区表索引重建/不可用

索引重建/不可用 使用ALTER INDEX可以设置索引是否可用。 例如，假设分区表range_ sales上存在索引range_sales_idx，可以通过如下命令设置其不可用。 ALTER INDEX range_sales_idx UNUSABLE; 可以通过如下命令重建索引range_sales_idx。 ALTER INDEX range_sales_idx REBUILD; 父主题： 分区表索引重建/不可用

分区表索引重建/不可用 用户可以通过命令使得一个分区表索引或者一个索引分区不可用，此时该索引/索引分区不再维护。使用重建索引命令可以重建分区表索引，恢复索引的正常功能。 此外，部分分区级DDL操作也会使得Global索引失效，包括删除drop、交换exchange、清空truncate、分割split、合并merge。如果在DDL操作中带UPDATE GLOBAL INDEX子句，则会同步更新Global索引，否则需要用户自行重建索引。 索引重建/不可用 Local索引分区重建/不可用 父主题： 分区表运维管理

分区表行迁移 用户可以使用ALTER TABLE ENABLE/DISABLE ROW MOVEMENT来开启/关闭分区表行迁移。 开启行迁移时，允许通过更新操作将一个分区中的数据迁移到另一个分区中；关闭行迁移时，如果出现这种更新行为，则业务报错。 如果业务明确不允许对分区键所在列进行更新操作，建议关闭分区表行迁移。 例如，创建列表分区表，并开启分区表行迁移，此时可以跨分区更新分区键所在列；关闭分区表行迁移后，对分区键所在列进行跨分区更新会业务报错。 CREATE TABLE list_sales ( product_id INT4 NOT NULL, customer_id INT4 PRIMARY KEY, time_id DATE, channel_id CHAR(1), type_id INT4, quantity_sold NUMERIC(3), amount_sold NUMERIC(10,2) ) PARTITION BY LIST (channel_id) ( PARTITION channel1 VALUES ('0', '1', '2'), PARTITION channel2 VALUES ('3', '4', '5'), PARTITION channel3 VALUES ('6', '7'), PARTITION channel4 VALUES ('8', '9') ) ENABLE ROW MOVEMENT; INSERT INTO list_sales VALUES (153241,65143129,'2021-05-07','0',864134,89,34); --跨分区更新成功，数据从分区channel1迁移到分区channel2 UPDATE list_sales SET channel_id = '3' WHERE channel_id = '0'; --关闭分区表行迁移 ALTER TABLE list_sales DISABLE ROW MOVEMENT; --跨分区更新失败，报错fail to update partitioned table "list_sales" UPDATE list_sales SET channel_id = '0' WHERE channel_id = '3'; --分区内更新依然成功 UPDATE list_sales SET channel_id = '4' WHERE channel_id = '3'; 父主题： 分区表运维管理

对二级分区表重命名二级分区 使用ALTER TABLE RENAME SUBPARTITION可以对二级分区表重命名二级分区。 例如，通过指定分区名将二级分区表range_list_sales的分区date_202001_channel1重命名。 ALTER TABLE range_list_sales RENAME SUBPARTITION date_202001_channel1 TO date_202001_channelnew; 或者，通过指定分区值将二级分区表range_list_sales中('2020-01-08', '0')所对应的分区重命名。 ALTER TABLE range_list_sales RENAME SUBPARTITION FOR ('2020-01-08', '0') TO date_202001_channelnew; 父主题： 重命名分区

对一级分区表重命名分区 使用ALTER TABLE RENAME PARTITION可以对一级分区表重命名分区。 例如，通过指定分区名将范围分区表range_sales的分区date_202001重命名。 ALTER TABLE range_sales RENAME PARTITION date_202001 TO date_202001_new; 或者，通过指定分区值将列表分区表list_sales中'0'所对应的分区重命名。 ALTER TABLE list_sales RENAME PARTITION FOR ('0') TO channel_new; 父主题： 重命名分区

对二级分区表移动二级分区 使用ALTER TABLE MOVE SUBPARTITION可以对二级分区表移动二级分区。 例如，通过指定分区名将二级分区表range_list_sales的分区date_202001_channel1移动到表空间tb1中。 ALTER TABLE range_list_sales MOVE SUBPARTITION date_202001_channel1 TABLESPACE tb1; 或者，通过指定分区值将二级分区表range_list_sales中('2020-01-08', '0')所对应的分区移动到表空间tb1中。 ALTER TABLE range_list_sales MOVE SUBPARTITION FOR ('2020-01-08', '0') TABLESPACE tb1; 父主题： 移动分区

对一级分区表移动分区 使用ALTER TABLE MOVE PARTITION可以对一级分区表移动分区。 例如，通过指定分区名将范围分区表range_sales的分区date_202001移动到表空间tb1中。 ALTER TABLE range_sales MOVE PARTITION date_202001 TABLESPACE tb1; 或者，通过指定分区值将列表分区表list_sales中'0'所对应的分区移动到表空间tb1中。 ALTER TABLE list_sales MOVE PARTITION FOR ('0') TABLESPACE tb1; 父主题： 移动分区

对二级分区表合并二级分区 使用ALTER TABLE MERGE SUBPARTITIONS可以将多个二级分区合并为一个分区。 例如，将二级分区表hash_list_sales的分区product1_channel1、product1_channel2、product1_channel3合并为一个新的分区，并更新Global索引。 ALTER TABLE hash_list_sales MERGE SUBPARTITIONS product1_channel1, product1_channel2, product1_channel3 INTO SUBPARTITION product1_channel1 UPDATE GLOBAL INDEX; 父主题： 合并分区

对一级分区表合并分区 使用ALTER TABLE MERGE PARTITIONS可以将多个分区合并为一个分区。 例如，将范围分区表range_sales的分区date_202001和date_202002合并为一个新的分区，并更新Global索引。 ALTER TABLE range_sales MERGE PARTITIONS date_202001, date_202002 INTO PARTITION date_2020_old UPDATE GLOBAL INDEX; 对间隔分区表的间隔分区完成合并分区操作之后，源分区之前的间隔分区会变成范围分区。 父主题： 合并分区

合并分区 用户可以使用合并分区的命令来将多个分区合并为一个分区。合并分区只能通过指定分区名来进行，不支持指定分区值的写法。 合并分区不能作用于哈希分区上。 执行合并分区命令会使得Global索引失效，可以通过UPDATE GLOBAL INDEX子句来同步更新Global索引，或者用户自行重建Global索引。 合并前的分区如果包含分类索引则不支持合并。 合并后的新分区，对于范围/间隔分区，可以与最后一个源分区名字相同，比如将p1,p2合并为p2；对于列表分区，可以与任一源分区名字相同，比如将p1,p2合并为p1。 如果新分区与源分区名字相同，数据库会将新分区视为对源分区的继承，这会影响合并期间对源分区查询的行为，具体请参见DQL/DML-DDL并发。 对一级分区表合并分区 对二级分区表合并二级分区 父主题： 分区表运维管理