# [Known Issue] Update unique key checks within the same region are not batched into a single BatchGet RPC ([tidb#55427](https://github.com/pingcap/tidb/issues/55427))

Source note: adapted from GitHub issue [tidb#55427](https://github.com/pingcap/tidb/issues/55427).

## Issue

- Link: [tidb#55427](https://github.com/pingcap/tidb/issues/55427)
- Summary: when an `UPDATE` modifies rows covered by unique indexes, TiDB performs uniqueness checks with KV Get requests. Even if the checked keys are in the same region, those requests may not be merged into a single BatchGet RPC, causing excessive KV RPC count and higher transaction latency.

## Phenomenon

- Write latency increases for multi-row `UPDATE` statements on tables with unique indexes.
- Slow query output or `EXPLAIN ANALYZE` shows an unexpectedly large `Get:{num_rpc:...}` count.
- At the same time, the read side of the plan may still show only one `cop_task`, which means the target keys are already in one region. The latency increase comes from uniqueness-check RPC fan-out rather than region scattering.

## Root Cause

When TiDB updates rows that affect unique indexes, it must check whether the new unique-key values already exist. In the affected code path, these point checks are sent as individual KV Get requests instead of being coalesced into one BatchGet RPC, even when:

- multiple checked keys belong to the same region
- the transaction updates multiple rows in one statement
- the execution plan already proves the scan phase is served by a single coprocessor task

As a result, TiDB sends many small KV RPCs for the uniqueness check stage, and transaction latency rises noticeably.

## Diagnostic Steps

1. When `INSERT` or `UPDATE` latency increases, inspect slow queries and look for statements on tables with unique indexes.

2. Check whether the slow query or `EXPLAIN ANALYZE` output contains a high KV Get RPC count, for example:

    ```text
    Update_4 ... Get:{num_rpc:15, total_time:6.83ms}
    ```

3. Compare the same workload on a similar table without unique indexes. If the unique-index table shows many KV Get RPCs while the non-unique-index table does not, the issue is likely present. Confirm that the target rows are still in one region. A typical signal is `cop_task: {num: 1}` in the scan phase, for example:

    ```text
    IndexRangeScan_9(Build) ... cop_task: {num: 1, ...}
    ```

4. If needed, reproduce with the following setup:

    ```sql
    SET @@tidb_slow_log_threshold = 300;

    DROP TABLE IF EXISTS t1, t2;
    CREATE TABLE t1 (
    id INT PRIMARY KEY,
    a INT,
    b INT,
    c INT,
    d INT,
    e INT,
    UNIQUE KEY (a, b),
    UNIQUE KEY (a, c),
    UNIQUE KEY (a, d)
    );
    CREATE TABLE t2 (
    id INT PRIMARY KEY,
    a INT,
    b INT,
    c INT,
    d INT,
    e INT,
    KEY (a, b),
    KEY (a, c),
    KEY (a, d)
    );

    INSERT INTO t1 VALUES
    (1, 1, 1, 1, 1, 1),
    (2, 1, 2, 2, 2, 2),
    (3, 1, 3, 3, 3, 3),
    (4, 1, 4, 4, 4, 4),
    (5, 1, 5, 5, 5, 5);
    INSERT INTO t2 SELECT * FROM t1;

    SET @@tidb_slow_log_threshold = 0;
    UPDATE t1 SET a = 2 WHERE a = 1;
    SELECT query, plan FROM information_schema.slow_query WHERE conn_id = connection_id();

    UPDATE t2 SET a = 2 WHERE a = 1;
    SELECT query, plan FROM information_schema.slow_query WHERE conn_id = connection_id();
    ```

    - A shorter reproduction is to run `EXPLAIN ANALYZE` directly:

        ```sql
        EXPLAIN ANALYZE UPDATE t1 SET a = 3 WHERE a = 2;
        EXPLAIN ANALYZE UPDATE t2 SET a = 3 WHERE a = 2;
        ```

    Expected observation:

        - `t1` uses one scan task but still shows many KV Get RPCs for uniqueness checks.
        - `t2` does not need those unique-key checks, so the write is much lighter.

## Workaround

Prefer one of the following alternatives when the workload is sensitive to latency:

- Use `INSERT ... ON DUPLICATE KEY UPDATE` instead of a multi-row `UPDATE` when the business logic allows it.
- Split the write flow into an explicit transaction and lock the target rows first:

```sql
BEGIN;
SELECT ... FOR UPDATE;
INSERT ... ON DUPLICATE KEY UPDATE ...;
COMMIT;
```

- Validate whether an upgraded release in your environment already includes the relevant optimization before relying on it as the permanent fix.

## Affected Version

- Reported as affecting all released versions at the time this note was written when the execution pattern triggers the unique-key check path.

## Fixed Version

- Not clearly documented in the original issue note.
- The main skill document notes that the fix may be related to [client-go#1411](https://github.com/tikv/client-go/pull/1411); verify the exact TiDB release that contains this dependency update before using it as a definitive fixed version.

## Related Oncall

- v7.5.2 slow update performance TCOC-2474
- v7.5 insert statement triggered over 20k BatchGet requests, causing overall slowness TCID-10713