---
metadata:
  - name: generator
    content: Diplodoc Platform v5.52.0
alternate:
  - https://ydb.tech/docs/en/troubleshooting/performance/schemas/splits-merges.md
  - https://ydb.tech/docs/ru/troubleshooting/performance/schemas/splits-merges.md
  - href: en/troubleshooting/performance/schemas/splits-merges.md
    type: text/markdown
    title: Markdown version
  - href: ../../../llms.txt
    type: text/markdown
    title: llms.txt
sourcePath: en/core/troubleshooting/performance/schemas/splits-merges.md
---
> **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/en/llms.txt

# Excessive tablet splits and merges


<!-- source: en/_includes/not_allow_for_olap_note.md -->
{% note warning %}

<!-- source: en/_includes/not_allow_for_olap_text.md -->
Supported only for [row-oriented](https://ydb.tech/docs/en/concepts/datamodel/table.md#row-oriented-tables) tables. Support for [column-oriented](https://ydb.tech/docs/en/concepts/datamodel/table.md#column-oriented-tables) tables is currently under development.
<!-- endsource: en/_includes/not_allow_for_olap_text.md -->

{% endnote %}
<!-- endsource: en/_includes/not_allow_for_olap_note.md -->


Each [row-oriented table](https://ydb.tech/docs/en/concepts/datamodel/table.md#row-oriented-tables) partition in YDB is processed by a [data shard](https://ydb.tech/docs/en/concepts/glossary.md#data-shard) tablet. YDB supports automatic [splitting and merging](https://ydb.tech/docs/en/concepts/datamodel/table.md#partitioning) of data shards which allows it to seamlessly adapt to changes in workloads. However, these operations are not free and might have a short-term negative impact on query latencies.

When YDB splits a partition, it replaces the original partition with two new partitions covering the same range of primary keys. Now, two data shards process the range of primary keys that was previously handled by a single data shard, thereby adding more computing resources for the table.

By default, YDB splits a table partition when it reaches 2 GB in size. However, it's recommended to also enable partitioning by load, allowing YDB to split overloaded partitions even if they are smaller than 2 GB.

A [scheme shard](https://ydb.tech/docs/en/concepts/glossary.md#scheme-shard) takes approximately 15 seconds to assess whether a data shard requires splitting. By default, the CPU usage threshold for splitting a data shard is set at 50%.

When YDB merges adjacent partitions in a row-oriented table, they are replaced with a single partition that covers their range of primary keys. TThe corresponding data shards are also consolidated into a single data shard to manage the new partition.

For merging to occur, data shards must have existed for at least 10 minutes, and their CPU usage over the last hour must not exceed 35%.

When configuring [table partitioning](https://ydb.tech/docs/en/concepts/datamodel/table.md#partitioning), you can also set limits for the [minimum](https://ydb.tech/docs/en/concepts/datamodel/table.md#auto_partitioning_min_partitions_count) and [maximum number of partitions](https://ydb.tech/docs/en/concepts/datamodel/table.md#auto_partitioning_max_partitions_count). If the difference between the minimum and maximum limits exceeds 20% and the table load varies significantly over time, [Hive](https://ydb.tech/docs/en/concepts/glossary.md#hive) may start splitting overloaded tables and then merging them back during periods of low load.

## Diagnostics

<!-- The include is added to allow partial overrides in overlays  -->
<!-- source: en/troubleshooting/performance/schemas/_includes/splits-merges.md -->
1. See if the **Split / Merge partitions** chart in the **[DB status](https://ydb.tech/docs/en/reference/observability/metrics/grafana-dashboards.md#dbstatus)** Grafana dashboard shows any spikes.

    ![](_assets/splits-merges.png)

        This chart displays the time-series data for the following values:

        - Number of split table partitions per second (blue)
        - Number of merged table partitions per second (green)

1. Check whether the user load increased when the tablet splits and merges spiked.

    [//]: # (TODO: Add user load charts)

    - Review the diagrams on the **DataShard** dashboard in Grafana for any changes in the volume of data read or written by queries.

    - Examine the **Requests** chart on the **Query engine** dashboard in Grafana for any spikes in the number of requests.

1. To identify recently split or merged tablets, follow these steps:

    1. In the [Embedded UI](https://ydb.tech/docs/en/reference/embedded-ui/index.md), click the **Developer UI** link in the upper right corner.

    1. Navigate to **Node Table Monitor** > **All tablets of the cluster**.

    1. To show only data shard tablets, in the **TabletType** filter, specify `DataShard`.

        ![](_assets/node-tablet-monitor-data-shard.png)

    1. Sort the tablets by the **ChangeTime** column and review tablets, which change time values coincide with the spikes on the **Split / Merge partitions** chart.

    1. To identify the table associated with the data shard, in the data shard row, click the link in the **TabletID** column.

    1. On the **Tablets** page, click the **App** link.

        The information about the table is displayed in the **User table \<table-name\>** section.

1. To pinpoint the schema issue, follow these steps:

    1. Retrieve information about the problematic table using the [YDB CLI](https://ydb.tech/docs/en/reference/ydb-cli/index.md). Run the following command:

        ```bash
        ydb scheme describe <table_name>
        ```

    1. In the command output, analyze the **Auto partitioning settings**:

        * `Partitioning by load`
        * `Max partitions count`
        * `Min partitions count`
<!-- endsource: en/troubleshooting/performance/schemas/_includes/splits-merges.md -->

## Recommendations

If the user load on YDB has not changed, consider adjusting the gap between the min and max limits for the number of table partitions to the recommended 20% difference. Use the [`ALTER TABLE table_name SET (key = value)`](https://ydb.tech/docs/en/yql/reference/syntax/alter_table/set.md) YQL statement to update the [`AUTO_PARTITIONING_MIN_PARTITIONS_COUNT`](https://ydb.tech/docs/en/concepts/datamodel/table.md#auto_partitioning_min_partitions_count) and [`AUTO_PARTITIONING_MAX_PARTITIONS_COUNT`](https://ydb.tech/docs/en/concepts/datamodel/table.md#auto_partitioning_max_partitions_count) parameters.

If you want to avoid splitting and merging data shards, you can set the min limit to the max limit value or disable partitioning by load.