# Placement Rules In Sql
+ Clusters deployed cross geo-location and cannot be accessed locally
+ Inability to isolate resources based on business
+ Difficult to provision resources and replica per business level

![left](./student-guide/diagram/PlacementRulesInSQLBefore_aa_001_20220515.png)

------------------------------------------------------------
Prior to TiDB 6.0, our TiDB cluster had the following issues in terms of data placement management capabilities:

- Clusters deployed across regions and cannot be accessed locally
       As can be seen from the figure, a user in Beijing needs to cross regions to NewYork to reads and writes the data of the T3 table. The reason is that we cannot specify the physical location where the table is stored when it is created.

- Inability to isolate resources based on business
       In the figure, NewYork's 3 users need to access the T4, T5 and T6 tables respectively. Coincidentally, most of the region data of the leader role in these three tables is distributed on the TiKV-5 server. If data can be placed according to business attributes, the three users can reads and writes T4 from different servers. , T5 and T6 tables will avoid hot spots.

- Difficulty allocating resources and replica per business level
       In the figure, 2 users in Tokyo need to access the T7 table, and the T7 table is also a very important table. We want it to have 5 replica, and the T8 table is a historical table. We hope that the T8 table can be stored on 3 servers with average performance TiKV-7, TiKV-9, and TiKV-10 without occupying the higher performance The TiKV-8 server, that is, the data placement needs to be separated from hot and cold.