本文介绍一种高效、可靠的分区策略，用于处理百万级数据：在指定最小分区大小的前提下，确保相同键值的元素不被拆分到不同分区中，从而满足数据库批量查询对连续键范围的需求。
本文介绍一种高效、可靠的分区策略，用于处理百万级数据：在指定最小分区大小的前提下，确保相同键值的元素不被拆分到不同分区中，从而满足数据库批量查询对连续键范围的需求。
在处理大规模数据（如 100 万条记录）并需分批调用数据库时，简单按固定大小切分列表（如 ListUtils.partition）虽高效，但存在关键缺陷：相同业务键（如 Car.key）可能被分散到多个分区，导致后续 DB 查询无法准确覆盖全部关联记录，甚至引发数据遗漏或重复处理。
例如，原始数据按 key 排序后为：[Car{key=1}, Car{key=2}, Car{key=2}, Car{key=3}, ...]
若强制按 chunkSize=2 切分，将得到：
- Partition 1:
[key=1, key=2] - Partition 2:
[key=2, key=3]
→key=2被割裂，违反“同键聚合”需求。
✅ 正确解法的核心前提是：数据需按键有序（sorted or clustered）。在此基础上，我们实现“粘性分区（sticky partitioning）”——当一个分区末尾元素的键与下一个元素相同时，自动扩展该分区边界，直至键值变化。
以下是推荐的工业级实现（Java 17+）：
import java.util.*;
import java.util.function.Function;
import java.util.stream.Collectors;
public class KeyAwarePartitioner {
/**
* 将列表按指定最小尺寸分区，并确保相同键的元素不跨分区。
* 要求：输入列表应已按 keyFunction 排序或聚类（clustering）。
*
* @param data 原始列表（非空）
* @param minSize 每个分区的最小元素数（非严格下限，因粘性扩展）
* @param keyFunction 提取分组键的函数
* @param <T> 元素类型
* @param <K> 键类型（需支持 equals，无需 Comparable）
* @return 分区后的嵌套列表
*/
public static <T, K> List<List<T>> partitionByKey(
List<T> data,
int minSize,
Function<T, K> keyFunction) {
if (data.isEmpty() || minSize <= 0) {
return Collections.singletonList(data);
}
// 若未排序，先聚类：保持首次出现顺序，为每个唯一键分配递增ID（稳定且轻量）
Map<K, Integer> keyOrder = new LinkedHashMap<>();
List<T> sortedOrClustered = data.stream()
.map(item -> {
K key = keyFunction.apply(item);
keyOrder.putIfAbsent(key, keyOrder.size());
return item;
})
.sorted(Comparator.comparing(keyFunction,
Comparator.comparing(keyOrder::get)))
.collect(Collectors.toList());
List<List<T>> result = new ArrayList<>();
for (int start = 0, end; start < sortedOrClustered.size(); start = end) {
// 初始结束位置：至少包含 minSize 个元素
end = Math.min(sortedOrClustered.size(), start + minSize);
// 粘性扩展：只要下一个元素键与当前分区最后一个元素键相同，就继续纳入
if (end < sortedOrClustered.size()) {
K lastKeyInPartition = keyFunction.apply(sortedOrClustered.get(end - 1));
while (end < sortedOrClustered.size()
&& Objects.equals(lastKeyInPartition,
keyFunction.apply(sortedOrClustered.get(end)))) {
end++;
}
}
result.add(sortedOrClustered.subList(start, end));
}
return result;
}
}? 使用示例：
record Car(long id, String name, long key) {}
List<Car> cars = List.of(
new Car(1, "Tesla", 1),
new Car(2, "Tesla-3", 2),
new Car(3, "Tesla-Y", 2),
new Car(4, "Tesla-S", 3)
);
// 按 key 分区，每块至少 2 条，但保证同 key 不拆分
List<List<Car>> partitions = KeyAwarePartitioner.partitionByKey(cars, 2, Car::key);
partitions.forEach(p -> {
long minKey = p.stream().mapToLong(Car::key).min().orElse(-1);
long maxKey = p.stream().mapToLong(Car::key).max().orElse(-1);
System.out.printf("DB Query: [%d, %d] → %d records%n", minKey, maxKey, p.size());
p.forEach(System.out::println);
});
// 输出：
// DB Query: [1, 2] → 3 records
// DB Query: [3, 3] → 1 record⚠️ 关键注意事项：
-
必须预排序/聚类：算法依赖键的局部连续性。若原始数据完全随机，建议先
stream().sorted(comparing(Car::key))—— 对 1M 数据，Arrays.sort()通常仅需 ~100ms。 -
性能友好：时间复杂度 O(n log n)（排序主导），空间 O(n)，无重复遍历；相比原方案中多次
subList+findFirst查找，本方案单次扫描完成。 - chunkSize 是下限而非精确值：实际分区大小 ≥ minSize，但绝不会拆分同键块，这是设计取舍。
-
泛型安全：
K无需实现Comparable，仅需equals()合理（如Long,String, 自定义对象重写equals/hashCode即可）。
? 总结：与其在无序数据上强行“模拟”键聚合（如你尝试的 distinctByKey + 反向索引查找），不如主动构建键的局部有序性，再以一次线性扫描完成智能分区——逻辑清晰、性能可控、易于测试与维护。
