已知数据范围：改变算法复杂度的第二个变量

写算法题也好，做业务系统也好，大部分人的第一反应都是：先看数据规模 n 是多少，然后套复杂度模板。但真正让我觉得"算法开窍"的时刻，是开始关注另一个维度——已知的数据范围。很多问题的复杂度天花板，根本不是由 n 决定的，而是由数据值域 M 决定的。

"根据已知数据范围选择算法"，听起来像一句废话，实际上是一套非常实用的方法论。你会发现：当你能提前确定输入值的取值范围和分布特征时，很多经典算法的性能可以被彻底改写。比如排序，比较排序的下界是 O(n log n)，但如果告诉你数据范围是 [0, 1000]，计数排序可以做到 O(n)，而且实现起来比快排还简单。这不仅仅是竞赛技巧，在真实工程里，面对有限枚举的状态、固定区间的计数器、已知 ID 集合的检索，这套思路每天都在替系统省下几个数量级的开销。

这篇文章我想把自己在实际编码和刷题过程中积累的经验整理出来——什么时候该用计数排序、位图、前缀和，什么时候死磕比较排序和哈希表，以及我踩过的那些与数据范围相关的坑。适合正在学算法的同学，也适合需要在真实场景里做性能优化的开发者。

1. 为什么已知数据范围能改变算法选型

1.1 传统复杂度框架里被忽略的第二个变量

我们习惯用输入规模 n 来衡量算法，比如排序 n 个元素是 O(n log n)、查找是 O(log n)。但这里的复杂度本质上只描述了一个维度：数据有多少条。它默认了一个假设——你不知道这些数据长什么样，只能通过"比较"来获取信息。

可现实里，我们往往还掌握另一个信息：数据的取值范围。设这个范围为 M，它代表所有可能取值的数量。一旦 M 已知，很多"比较"就不是必要的了。举个例子，你要给一个班的学生按成绩排名，成绩只可能是 0 到 100 分。你会挨个比较"小明的分数比小红高几分"吗？不会。你会直接拿一百零一个抽屉，谁多少分就扔进哪个抽屉，然后从高到低倒出来。抽屉就是"桶"，这就是计数排序的本质。

这个道理放生活里特别直白：物品只有红绿蓝三种颜色时，理出三个盒子分开放，比逐一比较每两件物品的色号快得多。算法的逻辑完全一样——数据范围 M 越小、越规整，你能利用的"结构信息"就越多。

1.2 已知范围告诉你的三件事

光知道"范围是 [0, M)"还不够，至少还要看三件事：

• 值域大小：M 与 n 的关系。如果 M 只是 n 的常数倍甚至更小，用数组、桶就很划算；如果 M 是 n 的几百上千倍，空间换时间可能亏本。
• 数据分布的密度：数据是紧凑连续地铺满整个值域，还是稀稀拉拉几个点？密集时直接开数组下标记值，稀疏时用哈希表或排序后二分更合理。
• 数据本身的特性：有没有负数需要偏移？是否要求稳定排序？是否涉及并发读写？这些约束会直接影响实现方案。

这三件事想清楚了，选型基本就定了七八成。后面所有讨论，本质上都是在围绕这三点做权衡。

2. 典型场景一：排序——用桶打败比较排序

2.1 计数排序：最暴力的加速方案

计数排序的正确打开方式是：前提是值域 M 不能太大，且已知确切上下界。核心步骤只有三块：统计频次、前缀和定位、回填输出。

python复制def counting_sort(arr, lower, upper):
    # 确定值域宽度并偏移处理
    size = upper - lower + 1
    count = [0] * size

    for x in arr:
        count[x - lower] += 1

    # 前缀和：count[i] 表示小于等于该值的元素个数
    for i in range(1, size):
        count[i] += count[i - 1]

    res = [0] * len(arr)
    # 倒序遍历以保持稳定性
    for x in reversed(arr):
        idx = x - lower
        count[idx] -= 1
        res[count[idx]] = x

    return res

复杂度是 O(n + M)，当 M ≤ n 时，它比快排和归并都狠。很多人一直以为计数排序只是"数数再倒出来"，过程确实简单，但有两个细节值得强调：

第一，前缀和并不是必须的。 如果只做"数数再展开"，直接遍历 count 数组把值铺回去也行，但那样不稳定，而且在一些需要保留原始顺序（比如按成绩排序同时要稳定输出同分学生的先后次序）的场景会出错。前缀和加倒序遍历是教科书标准写法，目的就是保证稳定性。

第二，有负数时做偏移。 值域 [-100, 100]，直接分配 201 个格子，映射下标时统一减去 -100（也就是加 100）。这个偏移量在后面的位图、桶排序里同样要处理，是个高频坑。

2.2 桶排序与基数排序：范围太大时的下一招

计数排序的短板很明显：M 一大，数组就撑不住。比如对 10^6 个数排序，值域却是 [0, 10^12]，总不能开一万亿个格子。这时候有两个变体方案：

桶排序的思路是先按区间把数据粗分到若干个桶里，每个桶内再用快排或递归桶排。它适用的状态是：当数据虽然不是"全集"，但相对均匀地分布在 [0, M) 内。比如统计 10 万条日志的时间戳，按小时分桶，每个桶内再排序，几乎线性。

基数排序则完全换了个角度——不直接按大小分桶，而是按位处理。从最低位到最高位，每一轮做一次稳定的"按位计数排序"。复杂度是 O(d(n + k))，其中 d 是最大位数，k 是每一轮的基数（通常取 10 或 256）。当 M 特别大但位数 d 很小（比如都是 32 位整数），基数排序往往比快排更有优势，尤其适合对字符串、长整型这类可以逐位切分的数据。

实际选型时我一般这样判断：M 在百万级别直接计数排序；M 很大但位数固定且不大，考虑基数排序；M 很大又不好按位拆，才退回快排或归并。看起来桶排好像很"万金油"，但桶的数量、每个桶内部排序的开销都不好控制，实战中反而最考验对数据分布的把握。

2.3 从一道排序题看决策路径

我印象很深的一道题是这样的：给出一组数，要求去重后按从小到大输出，n 最大 10^6，数的大小不超过 10^5。

按常规思路是快排加去重，O(n log n)，完全能过，但很多人的第一反应就是没必要。因为值域只有 10^5，而 n 有 10^6，意味着大量重复。直接用计数数组标记每个值是否出现过，然后扫一遍值域输出，复杂度 O(n + M)，去重也顺带完成了。代码只有十几行，比排序再 unique 快得多，而且输出天然有序。

这类题的共同特征就是"数据范围把解法焊死了"：要么 M 小到可以直接开数组，要么数据稀疏到需要哈希。每次拿到题目或者需求，先把输入约束写在草稿纸最顶上，再想算法，这是个非常值得养成的习惯。

3. 不只是排序：查找、去重与区间查询的场景

3.1 直接定址法与位图：存在性判断的极限优化

排序只是数据范围收益最明显的地方。做查找时，如果键的范围已知且不大，直接定址查找（把键当下标，数组存值或布尔标记）比任何平衡树和哈希表都快。

最惊艳的玩法是位图（bitset）。假设要判断一个 ID 是否在百万级别的集合里，且 ID 范围 [0, 10^8)，用布尔数组需要 100MB（每个 bool 按 1 字节算）。但如果只想知道"在不在"，用一个 bit 就够，总内存只有 10^8 / 8 = 12.5MB。如果用 C++ 的 std::vector<bool> 或者自己封装 uint64_t 数组，操作就是一次位运算的事。查询复杂度 O(1)，但常数极小，而且现代 CPU 对连续内存的缓存友好度远高于哈希表那样的随机跳转。

cpp复制#include <cstdint>
#include <vector>

class BitSet {
    std::vector<uint64_t> bits;
public:
    explicit BitSet(int max_range) : bits((max_range + 63) / 64) {}

    void set(int x) {
        bits[x >> 6] |= (1ULL << (x & 63));
    }

    bool contains(int x) const {
        return (bits[x >> 6] >> (x & 63)) & 1ULL;
    }
};

这段代码的核心就两个位运算：x >> 6 相当于除以 64 定位到哪个 uint64_t，x & 63 相当于模 64 定位到哪一位。我在实践中用它处理过一批固定范围的设备状态标记，上千万个状态位，内存占用比哈希表小了两个数量级，查询也没发生过一次 cache miss。

3.2 哈希表与数组下标的取舍

有人会问：那是不是只要有已知范围，就一律不用哈希表了？当然不是。哈希表赢在稀疏：如果值域 M 是 10^9，但实际只有 10^4 个键，开数组纯属浪费。此时 unordered_map 或 dict 更合适，因为它的内存跟 n 走，不跟 M 走。

我的取舍经验是：

• M 与 n 同数量级或 M 只是 n 的几倍：直接用数组或位图。
• M 远大于 n（比如差三个数量级以上）：用哈希表，或者把数据存下来排序后二分。
• 中间地带：看内存余量和性能要求。能接受 M 大小的一块连续内存时，数组访问依然是最好的选择，因为哈希表毕竟有哈希计算开销和可能的扩容抖动。

一句话总结：当你对值的分布有把握时，数组和位图永远比哈希表"朴素但更快"；只有把握不足或空间紧张时，哈希表才是退路。

3.3 前缀和与差分：把多次查询变成 O(1)

还有一种情况，数据范围不体现在"值"上，而体现在"查询的区间"上。比如一个数组表示 0 到 10^5 范围内每个分数的学生人数，需要频繁回答"分数在 [L, R] 之间有多少人"。

暴力做每次 O(R-L)，查询一多就炸。前缀和的思想是预处理一遍，pre[i] 表示 [0, i] 的累计人数，之后任意区间就是 pre[R] - pre[L-1]，单次查询 O(1)。因为值域有限，开一个跟 M 等长的前缀和数组完全可行。

这个套路在"静态数据 + 大量区间查询"的场景里几乎是标准答案。它跟排序不一样，不需要改变数据顺序，只做一次线性预处理，就把后续查询时间抹平了。配合差分数组（区间加、单点查）在处理一系列范围更新时同样常用。

4. 实测翻车现场与排查技巧

4.1 值域估计错误导致内存直接爆掉

有次我搭一个统计数据上报模块，一开始根据需求文档写死了值域是 [0, 10^6]，用 int 数组做计数。结果上线第二天就收到报警，某个字段偶尔会出现 10^9 级别的异常值，数组越界加内存耗尽一起爆发。

排查下来发现两件事：一是需求方的"合理范围"和真实数据的"实际范围"是有出入的，边界值总是超出你的想象；二是当时代码里没有做任何范围检查，数据一旦越界就是未定义行为。

现在我的习惯是：数组方案上线前，先跑一版真实数据统计 min/max，并在代码里加断言或拦截，超范围就降级到哈希表。这个自查流程花不了几分钟，但能省掉很多凌晨三点的紧急修复。

4.2 负数与偏移量：下标换算的经典错误

计数排序和位图都要求下标从 0 开始，所以负数必须整体平移到非负区间。我见过很多人栽在这里：值域是 [-10^4, 10^4]，结果分配数组时直接用 arr[x] 去访问，下标变负数直接崩溃。

正确做法是统一加偏移量 shift = -lower，访问时写 arr[x + shift]，遍历时也别忘了逆变换。有一个隐蔽的坑是偏移后位数计算：如果 lower = -100，upper = 100，数组长度应该是 upper - lower + 1 = 201，而不是 200。不少人在这个 +1 上反复丢分，建议写成通用函数而不是手算。

4.3 稀疏数据硬开大数组的空间浪费

另一个反面教训是"为了追求 O(1) 强行用数组"。某个离线任务需要给一批稀疏 ID 打标记，ID 最大到 10^9，实际只有几万个。我当时图省事直接 new bool[10^9]，一个 G 内存瞬间没了，还差点影响同机其他服务。

这种场景老老实实 unordered_set 几万条记录，内存几十 MB，查询也够快。数据范围已知不代表数据分布密集，知道"稠密还是稀疏"才是用不用数组类方案的前提。 判断标准很简单：n 与 M 的比值如果低于 1/1000，就基本告别直接定址了。

4.4 稳定性、并发与其他隐藏约束

最后说两个容易忽略的工程坑。第一是稳定性：计数排序倒序回填就是为了稳，如果你实现时图方便正序回填，同值元素的相对顺序会被破坏。业务里如果排序对象是"按分数排学生，但同分要保留报名顺序"，这个就非常重要。

第二是并发。位图看起来小巧，但多个线程同时 set 不同 bit 时，如果落在同一个 64 位整数的不同位上，直接按位或赋值是安全的；但如果逻辑是先读出来、改一位、再写回，并发场景就可能互相覆盖。要么用原子操作，要么给每个分块加锁。数据范围技巧往往出现在高性能模块里，这种细节一旦翻车，定位起来比普通逻辑错误痛苦得多。

最后再分享一个实战习惯

我后来养成了一个条件反射：拿到任何数据相关的任务，先问三个问题——数据有多少条、值域是什么、分布是稠密还是稀疏。哪怕答案只是"大概范围"，也能立刻过滤掉一半不合适的方案。很多时候，你不需要在算法本身上纠结，数据范围已经替你把答案写好了。

如果你也经常做排序、去重或者高频查询，下一次不妨刻意试用一下：先确认值域，再决定是快排还是计数、是哈希还是位图。这个思维转换的收益，比多背十个算法模板都实在。