# Solving Hotspots Performance Issues

+ The goal is trying the best to spread the TiKV Region Leaders evenly at two levels
+ Placement level: `Placement Driver` is responsible for balancing TiKV Region Leaders among TiKV nodes
+ Workload level: You are responsible for balancing the IO workload among TiKV Region Leaders, it is business logic related 
![`smart`](NoHotspot_en_001_20230906.png)

------------------------------------------------------------------------------
The effective solution to the hotspot issue is to distribute these TiKV Region Leaders across multiple TiKV nodes as much as possible. This ensures a possible balanced hardware utilization and is the ideal basic state for components in a distributed architecture.

When creating table structures in TiDB, you must ensure that the TiKV Region Leaders are distributed across multiple TiKV nodes evenly. The `Placement Driver` actually helps us accomplish this task automatically during the routine scheduling tasks, it is at the placement level.

What you need to do is to ensure that data is not concurrently accessed in the same TiKV Region at any given time, during the workload runtime. In other words, for our example of an insertion hotspot, you need to prevent the `AUTO_INCREMENT` property of primary key (clustered index), or prevent the system-generated `_tidb_rowid` (non-clustered index) from incrementing by a small number like 1 concurrently. Ideally, you should allocate multiple TiKV Regions for data accessing, even for a newly created empty table.