
# 分区表对导入操作的性能影响
在GaussDB中，相较于非分区表，分区表在数据插入处理流程中额外增加了分区路由环节的开销。
所以从整体来看，分区表场景下的数据插入开销主要由两部分构成，如[图1]所示：（1）heap-insert基表插入：此部分负责解决元组（tuple）存入对应堆表（heap表）的问题，并且这一操作在普通表和分区表中是通用的；（2）partition-routing分区路由：该部分主要解决分区路由问题，也就是要将元组插入到对应的分区表（partRel）中。
图1普通表\&分区表数据插入   
![](https://support.huaweicloud.com/distributed-devg-v10-gaussdb/figure/zh-cn_image_0000002620720457.png "点击放大")
因此对数据插入优化的侧重点如下：
- heap-insert基表插入：
  - 算子底噪优化。
  
  - heap数据插入。
  
  - 索引插入build优化（带索引）。
   
- partition-routing分区路由：
  - 路由查找算法逻辑优化。
  
  - 路由底噪优化，包括分区表partRel句柄开启、新增的函数调用逻辑开销。
  
  
  ![](https://support.huaweicloud.com/distributed-devg-v10-gaussdb/public_sys-resources/note_3.0-zh-cn.png)
  分区路由的性能在大数据量的单条INSERT语句执行时能得到显著体现。而在UPDATE场景中，其内部操作逻辑更为复杂，它需要先查找出对应要更新的元组，执行DELETE操作将其移除，之后再执行INSERT操作插入新的元组。相较于单条INSERT语句直接插入数据的场景，UPDATE场景的操作步骤更多，流程更繁琐，所以分区路由性能在UPDATE场景下的体现不如单条INSERT语句场景直接。
  
 
不同分区类型的路由算法逻辑如[表1]所示：
 表1路由算法逻辑 
| **分区方式**              | **路由算法复杂度** | **实现概述说明**           |
|:---|:---|:---|
| 范围分区（Range Partition） | O(logN)     | 基于二分binary-search实现。 |
| 哈希分区（Hash Partition）  | O(1)        | 基于key-partoid哈希表实现。  |
| 列表分区（List Partition）  | O(1)        | 基于key-partoid哈希表实现。  |
   
![](https://support.huaweicloud.com/distributed-devg-v10-gaussdb/public_sys-resources/notice_3.0-zh-cn.png)
分区路由的核心处理逻辑是依据导入数据元组的分区键来计算其所属分区，这是分区表相较于非分区表额外增加的开销。这部分开销对最终数据导入性能的具体影响，与服务器的CPU 处理能力、表的宽度以及磁盘和内存的实际容量相关。
通常情况下，可以进行如下粗略估算：
- x86服务器场景下分区表相比普通表的导入性能会略低10%以内。
- ARM服务器场景下数据导入性能约降低20%。
 
x86和ARM服务器在分区表导入性能上出现这种细微差异，主要原因是分区路由属于内存内计算强化场景，主流x86体系的CPU在单核指令处理能力方面稍强于ARM。
