# TiKV Region Hotspot
![`smart`](TiKVRegionHotSpot_aa_003_20231020.png)
------------------------------------------------------------------------------
We have learned that both tables, the table with clustered index for primary key and the table with nonclustered index for primary key, store rows as `key-value` pairs in the TiKV. A TiKV Region serves as the replication unit responsible for managing the `key-value` pairs it contains.

When accessing data, the TiDB server retrieves data from the TiKV Region which in turn is provided by the TiKV Region Leader by default.

During the table and primary key design, the objective is to evenly distribute the load of read and write operations across all TiKV Stores. This ensures that the benefits of the underlying TiKV distributed system are fully utilized, rather than having only a few TiKV Stores appear to be distributed while actually being overloaded, which can cause IO performance issues. 

When a concentrated workload of reading and writing is applied to a limited number of TiKV Region Leaders, rather than being evenly distributed, particularly in high concurrency situations, it results in a hot spot caused by hot TiKV Region(s). This is a situation that we must actively strive to prevent.

Therefore, an ideal scenario would involve evenly distributing the TiKV Region Leaders across TiKV Stores, as well as evenly distributing the I/O requests among all TiKV Regions. While the former is handled automatically by the TiDB cluster eventually, occasional human intervention may be necessary for the latter.

On the slide, there is an illustration of a TiKV cluster consisting of 3 TiKV Stores and a table with 3 TiKV Regions. However, we have encountered a situation where, at any given time, all sessions are simultaneously accessing data in the same TiKV Region (hot), while the other two TiKV Regions remain untouched (cold). As a result, the TiKV cluster is not being effectively utilized. This is typical scenario of TiKV Region hotspot.