# Full data migration - Create schemas in `TiDB Cloud`

```
CREATE DATABASE user_north;
CREATE TABLE user_north.information(id INT PRIMARY KEY, info VARCHAR(64));
CREATE TABLE user_north.trace(id INT PRIMARY KEY, content VARCHAR(64));

CREATE DATABASE user_east;
CREATE TABLE user_east.information(id INT PRIMARY KEY, info VARCHAR(64));
CREATE TABLE user_east.trace(id INT PRIMARY KEY, content VARCHAR(64));

CREATE DATABASE store;
CREATE TABLE store.store_bj(id INT PRIMARY KEY, pname VARCHAR(64));
CREATE TABLE store.store_tj(id INT PRIMARY KEY, pname VARCHAR(64));
CREATE TABLE store.store_sh(id INT PRIMARY KEY, pname VARCHAR(64));
CREATE TABLE store.store_suzhou(id INT PRIMARY KEY, pname VARCHAR(64));

CREATE DATABASE salesdb;
CREATE TABLE salesdb.sales(id INT PRIMARY KEY, pname VARCHAR(20), cnt int);
```

-------------------------------------------------------------
When creating schemas on the target database, please take note of the following issues or best practices:
- To distribute the workload evenly on multiple nodes, the design for the distributed database is different from traditional databases. The solution needs to ensure both low migration cost and logic correctness after migration. The following sections describe best practices before data migration.
    - `AUTO_INCREMENT` in `TiDB` is compatible with `AUTO_INCREMENT` in `MySQL`. However, as a distributed database, `TiDB` usually has multiple computing nodes (entries for the client end). When the application data is written, the workload is evenly distributed. This leads to the result that when there is an `AUTO_INCREMENT` column in the table, the `auto-increment` IDs of the column might be inconsecutive. For more details, see `AUTO_INCREMENT`.
    If your business has a strong dependence on `auto-increment` IDs, consider using the `SEQUENCE` function.
    - When you create a table, you can declare that the primary key is either a `clustered index` or a `non-clustered index`. see： https://docs.pingcap.com/tidb/stable/dm-best-practices#usage-of-clustered-indexes

- Data from multiple sharded tables might cause conflicts between the primary keys or unique indexes. You need to check each primary key or unique index based on the sharding logic of these sharded tables. The following are three cases related to primary keys or unique indexes:

    -（1）`Shard key`: Usually, the same shard key only exists in one sharded table, which means no data conflict is caused on shard key.
    -（2）`Auto-increment` primary key: The `auto-increment` primary key of each sharded tables counts separately, so their range might overlap. In this case, you need to refer to the next section Handle conflicts of `auto-increment` primary key to solve it.
    -（3）Other primary keys or unique indexes: you need to analyze them based on the business logic. If data conflict, you can also refer to the next section Handle conflicts of `auto-increment` primary key to solve it.
    see https://docs.pingcap.com/tidb/stable/shard-merge-best-practices#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables