分裂性能问题

TiDBer_oK6kPG05 · 2024 年9 月 11 日 03:25

最近在做tidb相关测试,发现分裂分区用时非常久,请问一下在以下情况会涉及数据的重整吗?如果答案为是的话，为什么要重整数据, 为什么不做成像region分裂那样只改元数据

小龙虾爱大龙虾 · 2024 年9 月 11 日 03:51

是的，分区表的分裂分区涉及到数据回填，所以耗时较久
为什么需要数据回填？因为分区表在设计上，底层数据组织方式不一样，仅变动元数据不行

zhaokede · 2024 年9 月 11 日 03:57

分片健值不一样。要把数据分到对应分区去。

kevinsna · 2024 年9 月 11 日 04:10

因为分区表的分裂不仅仅是元数据的变更，它还涉及到数据在物理存储上的重新分布，所以肯定会慢很多的

TiDBer_oK6kPG05 · 2024 年9 月 11 日 05:24

请问一下分区表具体是在底层怎么组织的, 有相关文档吗谢谢

懒云一笑 · 2024 年9 月 11 日 05:35

分区时物理存储上的分隔，肯定要重整数据，且费时

Defined2014 · 2024 年9 月 11 日 05:44

github.com

pingcap/tidb/blob/master/docs/design/2018-10-19-table-partition.md#how-the-partitioned-table-is-stored

# Proposal: Table Partition

- Author(s):     [tiancaiamao](https://github.com/tiancaiamao)
- Last updated:  2018-10-19
- Discussion at: https://github.com/pingcap/tidb/issues/7907

## Abstract

This proposal proposes to support the table partition feature.

## Background

MySQL has the [table partition](https://dev.mysql.com/doc/refman/8.0/en/partitioning.html) feature. If this feature is supported in TiDB, many issues could be addressed. For example, drop ranged partitions could be used to remove old data; partition by hash could address the hot data issue thus improve the write performance; query on partitioned table could be faster than on unpartitioned tables because of the partition pruning.

## Proposal

Implement the table partition feature step by step. Partition by range first, then partition by hash.

For current implementation in this proposal, subpartition is not considered. Reorganize partition involving data movement remains unsupported.

该文件已被截断。显示原文

小龙虾爱大龙虾 · 2024 年9 月 11 日 05:45

好像官方文档上还真没有，只有普通表的，参考: https://docs.pingcap.com/zh/tidb/stable/tidb-computing#表数据与-key-value-的映射关系
我猜测分区表的可能是把表 ID 换成了分区 ID，具体可能得看代码了

TiDBer_oK6kPG05 · 2024 年9 月 11 日 06:22

谢谢大家的回复 ,已经理解了因为底层存的是partition_id+row_id, 当partition变了需要重整所有数据