关于split index干过的那些不明不白的事。

🪐 TiDB 技术问题
1

请问打散表的同时是不是有必需和索引一起打散？

  1. split index是不是只有热点索引才去split？
  2. 能不能只split table而不split index
  3. split index还要区分索引类型，实际是太麻烦和复杂，假如一个组合索引包含数学列和日期列，像这样是什么类型进行split呢？文档真的仅仅只是文档，讲的不全面。
    索引
    索引1693×1860 489 KB
1 个赞
2

不是只热点索引才 split index：冷索引如需均衡分片也能手动 split，热点是最常用场景。

1 个赞
3

这个当然，我意思是如果热点表split后，索引是不是也要一起split，如果单独split表是不是也是可以的。

1 个赞
4

TiDB 打散表（如通过 SHARD_ROW_ID_BITS 或 DISTRIBUTE TABLE ）仅作用于表数据的 Region 分布，索引会自动随表数据一起打散，无需单独操作。‌

1 个赞
5

我的理解是，不管是表，还是索引，都是遇到问题了或场景有热点等的风险再考虑split，如果索引没有热点，就只split表就可以。毕竟split之后region变多也加重pd等的调度。

1 个赞
6

现在是已经有数据了且创建表的时候没有添加参加。所以现在只能手工打散。

1 个赞
7

我也是这样认为的，但官方只字不提，官方文档只是空理论，很多不切实际。

1 个赞
8

当发现索引成为性能瓶颈时，无论是由于热点问题还是其他原因（如索引过大、查询效率低下等），都可以考虑进行索引拆分

1 个赞
9

无索引热点只需拆分数据表，索引不用手动 split；过多 Region 会加剧 PD 调度开销，按需拆分即可。

1 个赞
10

TiDB 加索引是异步 DDL，内部通过 Online DDL 的 reorg 阶段渐进式构建。如果表数据量大，reorg 阶段会持续扫描和回填，这个过程中要保证集群有足够的 IOPS 资源。可以用 ADMIN SHOW DDL 监控进度。

1 个赞
11

Size Split（容量满自动拆）：所有索引 Region 写到 96MB 左右强制分裂，不管冷热，冷索引数据膨胀照样自动切 Region；
Load-Base-Split（负载分裂）：只针对读写超标热点索引 Region 自动拆分，冷索引无访问不会触发负载分裂

1 个赞
12

非热点索引随表 split 自动拆分，仅索引单点热点时手动 split index

1 个赞
13

支持只拆主键、不拆索引：原生分开命令，表和索引 Region 相互独立。

14

创建个新表，把数据搬过去就行了，看看效果在决定保留哪个

就是浪费点空间，可以的

15

容量分裂看数据大小，冷热全拆；负载分裂看访问流量，只拆热点。

16

TiDB 加索引是异步 DDL，内部通过 Online DDL 的 reorg 阶段渐进式构建。如果表数据量大，reorg 阶段会持续扫描和回填，这个过程中要保证集群有足够的 IOPS 资源。可以用 ADMIN SHOW DDL 监控进度。

17

手工打散

18

TiDB 中组合索引（含数学列和日期列）的 Region Split 是按索引值的字节序编码后进行 Range 切分的，类型本身不决定分裂方式，而是由索引列的编码顺序和值的字典序决定。‌‌

19

热点表 / 索引可分开手动分裂，索引支持按各类字段切分；集群默认 96MB 自动分 Region，热点索引会负载分裂；大索引 DDL 异步执行，留意 IO 压力。

20

打散表不是必须同步打散索引，仅当索引存在读写热点时，才需要执行SPLIT INDEX做索引打散，无热点的冷索引无需额外操作。