tidb数据表用你自增好，还是random好，如果是自增会不会出现热点问题
random好，自增会出现热点问题
但业务中可能出现用id去深度翻页查询，不自增好像不好查
如果业务必须依赖id的连续递增性，那只能用AUTO_INCREMENT
热点 未必会有，看你们业务量，用了nvme ssd并且还有一秒写入10万条以上数据要求可以考虑下这个问题，如果io负载不高自增就行
建表的时候提前拆分region，避免热点问题就行了。只不过要注意建表以后马上要开始导入数据，不然region会合并的
嗯，根据业务情况去
这个针对历史数据迁移可能用得到
根据业务需求设计
tidb用自增和mysql不同，不同版本tidb自增也有不同
AUTO_INCREMENT 是用于自动填充缺省列值的列属性。当 INSERT 语句没有指定 AUTO_INCREMENT 列的具体值时，系统会自动地为该列分配一个值。
出于性能原因，自增编号是系统批量分配给每台 TiDB 服务器的值（默认 3 万个值），因此自增编号能保证唯一性，但分配给 INSERT 语句的值仅在单台 TiDB 服务器上具有单调性。
在 TiDB 各个版本中，AUTO_ID_CACHE 设置为 1 都表明 TiDB 不再缓存 ID，但是不同版本的实现方式不一样：
- 对于 TiDB v6.4.0 之前的版本，由于每次分配 ID 都需要通过一个 TiKV 事务完成
AUTO_INCREMENT值的持久化修改，因此设置AUTO_ID_CACHE为1会出现性能下降。 - 对于 v6.4.0 及以上版本，由于引入了中心化的分配服务，
AUTO_INCREMENT值的修改只是在 TiDB 服务进程中的一个内存操作，相较于之前版本更快。 - 将
AUTO_ID_CACHE设置为1表示 TiDB 使用默认的缓存大小30000。
random
并发不大用自增，并发大用random
不对写入性能有极致的要求，自增就行
主键一般不用于业务查询，不建议用深度分页，性能不好的
写入量大的话用random，反之用自增
自增就行
random好，自增会出现热点问题，即使自增也不是全局连续的
自增，除非业务有特别要求
若有深度分页，建议自增
看业务上是用于前端的还是后端的，前端的要分页，使用AUTO_INCREMENT，如果是纯后端业务使用，又怕热点，那就使用random
random好