# Best Practices for Using the Primary Key in TiDB
+ For general IO performance and storage space considerations
  + Use clustered 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
+ Clustered primary key
  + Conditions: Must have a primary key (BIGINT)
  + Features: The key of the key-value pair should include the primary key.
  + Issue: AUTO_INCREMENT property may result in hotspots.
  + Solution: Change AUTO_INCREMENT to AUTO_RANDOM.
+ Non-clustered primary key
  + Condition 1: No primary key
  + Condition 2: Has primary key (BIGINT), but specified as Nonclustered Index
  + Feature: Using RowId as the key (automatically generated auto-increment column by TiDB database itself)
  + Issue: Continuous insertions may lead to hotspots
  + Solution: Set the SHARD_ROW_ID_BITS and PRE_SPLIT_REGIONS properties.
------------------------------------------------------------------------------
Best Practices for table design in TiDB Database
Table design in TiDB
Clustered Index
Conditions: Must have a primary key (BIGINT)
Features: The key of the key-value pair should include the primary key.
Issue: AUTO_INCREMENT property may result in hotspots.
Solution: Change AUTO_INCREMENT to AUTO_RANDOM."
Nonclustered Index
Condition 1: No primary key
Condition 2: Has primary key (BIGINT), but specified as Nonclustered Index
Feature: Using RowId as the key (automatically generated auto-increment column by TiDB database itself)
Issue: Continuous insertions may lead to hotspots
Solution: Set the SHARD_ROW_ID_BITS and PRE_SPLIT_REGIONS properties