【 TiDB 使用环境】测试
【 TiDB 版本】5.4
【遇到的问题】含有主键的表如何进行热点分散，非聚簇索引表可以直接设置SHARD_ROW_ID_BITS参数，但如果表本身有主键是不能设置的，这个如何解决？
【复现路径】mysql> CREATE TABLE t (a BIGINT PRIMARY KEY AUTO_RANDOM, b varchar(255) )SHARD_ROW_ID_BITS = 4;
ERROR 8200 (HY000): Unsupported shard_row_id_bits for table with primary key as row id
【问题现象及影响】
业务中所有的表都含有主键，这种是不是遇到热点就无法解决了？
【附件】
请参考https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#%E4%BD%BF%E7%94%A8-shard_row_id_bits-%E5%A4%84%E7%90%86%E7%83%AD%E7%82%B9%E8%A1%A8和https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#%E4%BD%BF%E7%94%A8-auto_random-%E5%A4%84%E7%90%86%E8%87%AA%E5%A2%9E%E4%B8%BB%E9%94%AE%E7%83%AD%E7%82%B9%E8%A1%A8
AUTO_RANDOM本身就是打散的
谢谢 各位 如果 打散后依然出现热点 怎么解决呢
使用AUTO_RANDOM依然出现了热点吗
我是说假设，如果再出现，继续打散？如果继续打散，如何打散，因为目前有个业务考虑腰用TIDB替代MYSQL，有些情况我得提前考虑进去
AUTO_RANDOM本身就是随机的，如果这样都能产生热点，那系统压力应该相当大了，考虑加节点吧
好的，看来也只能这样了，起码知道在一种情况发生后，该如何做 谢谢
还有一种可能是比如大量请求频繁查询一个小表这种单一 Region 形成的热点，可以手动拆分region或者考虑用6.0的缓存表特性去优化。
感谢 手动拆分region能否给个文档链接 学习一下
tidb官方文档中有专门关于热点问题处理的章节，如果这些方法都不能解决你的问题的话，那可以考虑选择其他技术了，比如redise。
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#tidb-热点问题处理
hash分区
用了 AUTO_RANDOM，通过主键读写表已经打散了，不会出现热点。但是如果表中创建了二级索引，若并发量较高，二级索引可能会形成热点。可以继续对索引进行打散。
如果在日期字段（日期精确到天或者小时）上创建索引，这样的二级索引是不是在并发量大的时候，就会容易造成热点。
索引热点通常出现在同一时刻向单调递增字段插入数据，或者同一时刻插入大量重复值的场景。这里的索引热点指单调递增字段或重复值字段上的索引。
根据索引的 KV 映射原理，可知：
非聚簇表的主键或唯一索引中的索引 Key 结构为：表ID_索引ID_索引列值。当单调递增字段同一时刻，批量插入数据时，索引 Key 必然也是连续的，会同时写入一个 Region 中，从而形成写热点。因此，若您批量插入数据时的日期字段为now()这种自动获取的值，则会产生热点。
普通二级索引的 Key 结构为：表ID_索引ID_索引列值_表的 RowID。若同一时刻，插入大量重复值时，也会产生写热点。
auto_random就不能保证有序性，这个要注意下
auto_random就是随机
