【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
mysql改成tidb架构：
流水型表改成tidb的单表,
1.单表最极端时每天可能1亿的数据量，这种使用id主键是auto increment是否会有热点表的问题，因为存在历史数据迁移，无法直接使用random随机产生id，能否有具体可行的优化方式？如果后续在切换为tidb时真的在线改成random id是否可行?
2.该表在tidb也为分区表的话，如果后续最多保留2个月的数据，之前的数据通过exchange parition的方式交换出去，这个表的region个数是否直接减少。而且如果按照1中所提的改成了random id，会产生重复的交换出去的分区的id嘛？
1.我的理解，你新入的数据可以通过指定auto_random来进行写热点打散，历史数据迁移问题，可以通过指定 AUTO_RANDOM_BASE 参数，来新入数据的id和老数据不会重复。
2.auto_random生成的值具有唯一性，只要你生成过这个random值，即使你exchange出去了，后面也不会再生成同一个random值了。
我测试下，感谢。
1，如果你想改这个字段的类型，上面已经给了你方案。
如果你不想改这个字段的类型，可以使用非聚簇表+SHARD_ROW_ID_BITS+PRE_SPLIT_REGIONS：
分裂region的个数可以视情况调节，从我个人的经验来讲：大量写入的时候如果不是所有的机器负载都高，而是集中在几台，可能就是分裂的个数有点小了。
建表语句类似下面这样，注释包裹的部分是必须的：
CREATE TABLE UserCardLog_date (
Id int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (Id,) /*T![clustered_index] NONCLUSTERED */
) ENGINE=InnoDB /*T! SHARD_ROW_ID_BITS=4 PRE_SPLIT_REGIONS=4 */;
文档位置：
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#使用-shard_row_id_bits-处理热点表
2,id不会重复。
你好，还想咨询下，你知道这个SHARD_ROW_ID_BITS 有具体的计算公式或者设置跟什么有关系嘛，比如跟底层tikv节点个数，插入并发数，还是什么有关联，目前测试的可能我们48亿的数据底层region在23000左右。
前提条件:
PRE_SPLIT_REGIONS=4是预先分裂为16个region。
且PRE_SPLIT_REGIONS不能比SHARD_ROW_ID_BITS大。
和tikv节点的个数的关系：
我实际使用中，有4个tikv，但是我设置PRE_SPLIT_REGIONS=2,即预先分裂4个region的时候有一台tikv的写入负载一直没起来。
当我设置PRE_SPLIT_REGIONS=4，即预先分裂16个region的时候，4个tikv在大量写入的情况下，cpu和io都能到一个比较高的水平。
如果你的tikv实例多，我觉得你可以尽可能多的预先分裂一些region出来。
我的使用感受是：预先分裂的region数量和tikv实例数量保持一致的情况下，未必能保证负载是均衡的。稍微大一些会容易均衡一些。
和插入并发的关系：
我这边的情况是，连接数稍微高一些，但tps/qps很低。所以总体并发在一个表上只会更低。这方面我没有经验。也给不了建议。
好的，十分感谢帮忙。
写入和tikv物理节点数量有关系，也和nvme硬盘性能有关，都要综合考虑和测试
好的，准备上的是tikv节点是物理机，其他是虚机.
tikv可以用虚拟机，但是硬盘建议用单独的一块数据盘做直通分给虚拟机，这样就不会因为虚拟化硬盘损失IO性能，比如exsi配置pci的nvme硬盘直通，参考以下：
尽量用真机，虚机不会太理想。。。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。