问Redis 集群版直连模式下批量读写报 CROSSSLOT，应如何改造业务？

场景：腾讯云分布式缓存（兼容 Redis）7.0 集群架构，3 分片、每分片 1 副本，连接模式选的直连模式。业务是 Java 8 + Jedis 5.1.2，原来用标准架构主从实例（JedisPool），通过 DTS 迁到集群版后改用 JedisCluster。

现象：

1. 订单详情接口一次 mget 十几个 key（如 order:status:10086、order:amount:10087，属于不同订单），应用抛 JedisClusterOperationException，提示 keys 属于不同 slot；用 redis-cli 连分片地址手动执行 MGET，返回 CROSSSLOT Keys in request don't hash to the same slot。
2. 库存扣减的 Lua 脚本同时操作 stock:A100 和 sold:A100 两个 key，同样报 CROSSSLOT。
3. 夜间清理任务原来用 SCAN 按前缀遍历过期会话，现在只扫到大约三分之一的 key，DBSIZE 也明显小于迁移前核对的总数。
4. 同一份代码连回原标准架构实例一切正常。

已尝试：

1. 新写入的 key 改成 order:{10086}:status 这种带哈希标签的写法，单订单内的 mget 和 Lua 可以正常执行。
2. 跨订单的批量读取临时改成按 slot 分组后分多次 mget，可用，但代码改动面大，不确定方向是否正确。

问题：

1. 有几十万个存量 key 不带哈希标签，如何在业务不停写的前提下迁到新命名规则，并让读取同时兼容新旧 key？
2. 直连模式下跨订单批量读取，按 slot 分组并行 mget 和 pipeline 哪个更合适？
3. 全量前缀扫描应该怎么做才不漏 key？是对每个分片地址分别 SCAN 吗，分片地址去哪里获取？
4. 如果业务改造成本太高，换成代理模式更合适吗？我理解连接模式创建后不能切换，只能新建实例再迁移，这个判断对吗？