# Hotspot Caused by Concurrent Insertions `AUTO_INCREMENT` - Example 

```
tidb> CREATE TABLE sbtest1(
  ~!@id INT PRIMARY KEY AUTO_INCREMENT@!~,
  k INT NOT NULL DEFAULT '0',
  c CHAR(120) NOT NULL DEFAULT '',
  pad CHAR(60) NOT NULL DEFAULT ''
);

tidb> SELECT region_id, start_key, end_key
  FROM information_schema.tikv_region_status
  WHERE table_name='sbtest1';
+-----------+--------------------------------------+---------+
| region_id | start_key                            | end_key |
+-----------+--------------------------------------+---------+
|      5005 | 7480000000000000FFBD00000000000000F8 |         |
+-----------+--------------------------------------+---------+
~!@1 row@!~ in set (0.02 sec)
```

![`smart`](TiKVRegionHotSpotInsertionAutoIncrement_en_001_20230906.png)
------------------------------------------------------------------------------
The slide provides a specific example of a hotspot that occurs due to concurrent insertions, and the TiKV Region split is ineffective in addressing the resulting performance problems automatically.

`AUTO_INCREMENT` is a commonly used primary key attribute in traditional schema design, however, it can lead to hotspot in scenarios with high concurrency of new rows insertion.

In the given example, `sbtest1` is a table with clustered index for primary key, the `AUTO_INCREMENT` attribute is used to generate a unique `id` value for each row, with a default increment of 1. 

In scenario `(A)`, from the start, the table consists only of one TiKV Region and consequently one Region Leader. Consequently, all simultaneous `INSERT` requests are handled by a solitary TiKV node, such as `TiKV Store A`. `Region 1` is the hotspot.

In scenario `(B)`, when `Region 1` exceeds the Region split threshold, it splits into two TiKV Regions, namely `Region 1-1` and `Region 1-2`, while still residing on the same `TiKV Store` called `TiKV Store A`. In this specific example, the other two nodes, `TiKV Store B` and `TiKV Store C`, do not contribute. `Region 1-2` becomes the hotspot.

In scenario `(C)`, eventually `Placement Driver` re-balances the `TiKV Region Leader` distribution, as a result `Region 1-2` is relocated to `TiKV Store B`, and the other two nodes, `TiKV Store A` and `TiKV Store C`, do not assist to share the insertion workload. `Region 1-2` is the hotspot.

These hotspot TiKV nodes (caused by hot TiKV Regions) become the performance bottleneck of the entire TiKV cluster. In the TiDB with severe hotspot performance issues, there is often a drop in read and write performance, and the overall TiDB system's throughput might fails to meet business requirements.