运行时期修改的话，会涉及数据迁移，这是一个非常麻烦的操作。
比如说你原先按100分表，运行一段时间后修改配置成按1000分表。
原来有一条数据id=1321，那么这个数据按100分表时在 tablexxx_21 里。
调整规则按1000分表后，这个数据就不应该在 tablexxx_21 里，而应该在 tablexxx_321 表里。
带来的问题就是，需要把旧数据都重新hash后移动位置。如果只切换规则，不迁移数据，会导致查询不到数据。
--
Kimm King(kimmk...@apache.org/kimmk...@163.com)
Apache Dubbo&ShardingSphere PMC Member
github&twitter: kimmking
在 2023-09-04 13:37:56，"360346...@qq.com.INVALID" <360346...@qq.com.INVALID> 写道：
>
>您好：
> 首先非常感谢开源出来这个好的中间件。 我对其中一个配置的有些疑问，希望能得到您的解惑。
>
> 我的业务场景：基于若依改造的微服务。分表是根据业务自动创建的，并不是事先创建好的。创建的分表在多个服务中都会用到。我现在的做法是创建分表后重新刷新数据源的信息。
> 这种方式需要在多个微服务中同时都刷新数据源。
> 我经过测试发现，如果我将actual-data-nodes:
> ds0.bill_info${1..100}配置的范围包含了我未来会创建的分表序号的情况下，不需要刷新数据源也可以获得分表信息。我想了解下，如果我把分表信息从1..100修改为1..1000或者1..10000会有什么问题吗？
> 下面是我的配置：
> sharding:
> # 按表来区分
> tables:
> bill_info:
> # 配置数据节点
> actual-data-nodes: ds0.bill_info${1..100}
> tableStrategy:
> inline:
> shardingColumn: no
> algorithmExpression: bill_info${no}
> key-generator:
> column: billid
> type: snowflake
> props:
> worker.id: 1
> max:
> tolerate:
> time:
> difference:
> milliseconds: 60000
>
>
>360346...@qq.com
