实际很容易出现扫描所有Region，我们之前在按随机主键拆批删除的时候就出现过因为扫描太多Region而导致TiDB节点OOM。
对，我理解也是随机主键主要是为了解决热点问题，但是在一些场景中随机主键也有局限性，比如使用随机主键去拆批容易导致扫描太多Region。
有什么具体的案例或者验证吗？
你是说拆批完成后的批处理SQL吗，那个得走索引的
走索引你是基于什么进行拆批？
1.主键都随机了，还有什么场景根据主键删除和更新。
2.写入有热点可以建表加上SHARD_ROW_ID_BITS。
3.非聚簇表应该可以解决。
根据啥都可以啊，聚簇表根据主键，非聚簇根据隐藏的rowid
首先业务主键会导致主键过长，占用磁盘多，另外一点主键很可能被更新
聚簇表的话只是key大了一点，主键被更新各种业务里面都很罕见
1 个赞
想要删除快还是要靠分区。
不太清楚是否有个明确的业务逻辑能支持这些要批量删除的数据在一个分区上。
这样问题就会简单很多。
主键的选择也就变简单了。
嗯嗯，我们类似历史表这种有设置分区表，并通过脚本对分区表进行了生命周期管理，但是并不是所有的场景适合用分区表做，有些用不了分区表，但是需要进行拆批删除或者更新之类的。
1 个赞
比如随机主键的聚簇表根据随机主键去拆，就有问题了，很容易出现扫描大量Region的情况，我们之前有出现过按随机主键拆批删除导致TiDB节点OOM。
1、涉及拆批删除需要基于某个字段，用到随机主键也正常吧；
2、使用打散参数，我们有压测过，会对查询效率有影响；
3、非聚簇表如何解决拆批的问题（可用隐式的_tidb_rowid），但是又会遇到一个问题，如果涉及到大数据量导入会出现热点问题；
扫描region数量变多可以理解，数据可能更散，但是导致TiDB OOM不太懂为啥
因为在执行过程中因随机主键的原因导致扫描的Region数过多，执行过程中占用内存就过大了，导致TiDB节点内存溢出。
涉及到大量数据删除只能用分区表，普通表delete有几个问题无解，比如硬盘空间不释放、一次删太多oom,删了没 gc+compact也是要扫描删除的数据、还有删除大量数据会导致磁盘短时间内使用空间激增。
目前而言，主要还是对于既需要导入数据，有需要拆批delete数据但还不能使用分区表的场景，比较无解。