# Best Practices for Using the Primary Key in TiDB
+ For general IO performance and storage space considerations
  + Use clustered index for primary key whenever feasible
  + No need to define a primary key when your table does not have a suitable primary key 
+ To mitigate the TiKV Region hotspot performance issue
  + Use **`AUTO_RANDOM`** whenever feasible
  + Use **`PRE_SPLIT_REGIONS`** attribute for new table for better TiKV Region distribution
  + Use **`SPLIT TABLE`** SQL command for existing table for better TiKV Region distribution
  + Use **`SHARD_ROW_ID_BITS`** to shard primary key values when work with non-clustered primary key
------------------------------------------------------------------------------
Based on the comparison of read `(SELECT)` and write `(INSERT/UPDATE/DELETE)` operations between the clustered index and non-clustered index, you can conclude that generally when a table includes a primary key column and requires frequent data access (query or modifications) based on the primary key, it is optimal to design it as a table with clustered index for primary key as possible, it saves storage space and reduces IO operations compared to a table with non-clustered index for primary key. 

If a table does not have a primary key constraint intentionally, there is no need to manually add or create a primary key column since TiDB already provides a implicit primary key called `_tidb_rowid`. This situation applies to the use of non-clustered indexes for implicit primary key scenarios. In fact, every table in TiDB has a unique index that supports its primary key, whether it is explicitly or implicitly declared

`AUTO_RANDOM` evenly distributes the data across the TiKV Stores, guaranteeing uniform workload distribution, especially during insertion operations. This approach effectively prevents the occurrence of hotspots.

The `PRE_SPLIT_REGIONS` attribute and the `SPLIT TABLE` command aid in proactively balancing TiKV Regions across TiKV Stores, effectively reducing hotspot issues from the outset. These features are commonly used alongside `AUTO_RANDOM` or `SHARD_ROW_ID_BITS` for clustered and non-clustered indexes respectively.