Dynamically Modifying Primary Keys and Capacity Assessment

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 动态修改主键、容量评估

| username: Hacker_ythhI9Qd

[TiDB Usage Environment]
TiKV, 32C 64G

[TiDB Version]
5.7.25-TiDB-v4.0.10

  1. Currently, the table id primary key is incremental. Can it be modified to auto_random and simultaneously increase SHARD_ROW_ID_BITS? If it cannot be modified, and the only way is to create a new table and migrate data from the old table to the new table, it should not be possible to directly insert the old table id into the new table.

  2. The maximum concurrency for a single table is 1000, with 400 million records per year and 3 associated tables. Besides adjusting auto_random and SHARD_ROW_ID_BITS=6, the business mainly queries data from the past year. Is it necessary to archive data and add partitions monthly? Will SHARD_ROW_ID_BITS=6 affect query performance?

2
| username: xfworld | Original post link

  1. auto_random does not support SHARD_ROW_ID_BITS, and the old table’s ID cannot be used during migration.

  2. SHARD_ROW_ID_BITS will affect the ability to scatter data across Regions (scattering ensures that each TiKV node has evenly distributed Regions, preventing read/write hotspots). If you use partitioning, please ensure that each partition has [effective] data; otherwise, it may be slower than not partitioning at all…

Additionally, you might consider upgrading the version…

3
| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.