Why is the data still written to a single partition table when using hash partitioning?

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

Original topic: 使用hash分区,为什么写入的数据还是在一个分区表上呢

| username: madcoder

[Test Environment for TiDB]
[TiDB Version]
[Reproduction Path] Using an auto-increment ID as the primary key can cause write hotspot issues. We need to keep the auto-increment ID as the primary key and consider using hash partitioning. Manually insert four pieces of data. These four pieces are indeed on four partition tables. Then use sysbench for stress testing. The result shows a large number of writes in one partition table, and the auto-increment IDs are 4, 8, 12, etc.
Why is this happening? If we need to keep the auto-increment ID as the primary key, what are some good solutions to this write hotspot issue?

| username: Jellybean | Original post link

You can use auto_random to solve it.

| username: YuchongXU | Original post link

Please provide the Chinese text you would like translated into English.

| username: TIDB-Learner | Original post link

If you need to use an auto-increment field and sort by chronological order, it is better to use a timestamp. TiDB recommends using auto_random to avoid hotspots.

| username: DBAER | Original post link

It seems that this kind of hotspot writing cannot be avoided. How about trying with more partitions?

| username: 数据库真NB | Original post link

auto_random

| username: madcoder | Original post link

Using hash partitioning, but the result is still written to a single partition table.

| username: TiDBer_rvITcue9 | Original post link

auto_random

| username: zhang_2023 | Original post link

auto_random

| username: 有猫万事足 | Original post link

auto random is the first choice.

If it can’t be done, then it can only be

CREATE TABLE t (
Id int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (Id) /*T![clustered_index] NONCLUSTERED */,
) ENGINE=InnoDB /*T! SHARD_ROW_ID_BITS=3 PRE_SPLIT_REGIONS=2 */

/*T![clustered_index] NONCLUSTERED */ non-clustered table
/*T! SHARD_ROW_ID_BITS=3 PRE_SPLIT_REGIONS=2 */

| username: TiDBer_LM | Original post link

auto_random

| username: zhanggame1 | Original post link

The relationship between write hotspots and partitioning is not significant; it’s still auto_random.

| username: zhaokede | Original post link

Was it tested with a single thread and single connection?

| username: TiDBer_HErMeXDz | Original post link

auto_random

| username: madcoder | Original post link

It was not tested with sysbench, the configuration is for 64 threads.

| username: madcoder | Original post link

To summarize: There is currently no suitable solution for this issue, so we can only consider the following points:

  1. Improve the machine’s performance to achieve higher TPS.
  2. Implement auto-increment IDs yourself.
  3. Use rate limiting to smooth out peaks.