Python set查找快因哈希表平均O(1)，但创建慢因需逐个hash并处理冲突；数据量大、字符串长或未重写hash时更明显，内存占用可达原始数据3–5倍。
Python set 查找为什么快，但创建很慢？
set 底层是哈希表，平均 O(1) 查找确实快，但初始化时要把所有元素 hash 并处理冲突——数据量上亿时，这个过程会明显卡顿，尤其当元素是长字符串或自定义对象（没重写 <strong>hash</strong> 和 <strong>eq</strong>）时，开销更大。
- 大量重复字符串：用
set(list_data)比用{x for x in list_data}稍快，但差别不大；真正影响性能的是字符串本身长度和内存分配 - 从文件逐行构建：别用
set(line.strip() for line in f)，改用set()实例 + 循环.add()，能减少中间生成器开销 - 内存占用高：一个空
set初始约 200 字节，但装入千万级元素后，实际占用常达原始数据 3–5 倍内存（因哈希表预留空槽）
1000 万以上数据，set 去重比 list 好多少？
在纯去重场景下，set 仍是唯一可行选择：list 的 if x not in lst 是 O(n)，1000 万数据可能跑数小时；而 set 整体耗时通常在秒级（取决于硬件和数据分布）。
- 实测对比（i7-11800H, 32GB）：
- 1000 万随机整数：
set(data)≈ 0.8s；list去重 ≈ 42 分钟 - 1000 万短字符串（平均 12 字符）：≈ 2.3s
- 1000 万长字符串（平均 200 字符）：≈ 6.7s（hash 计算变重）
- 1000 万随机整数：
- 注意：如果只是判断“是否存在”，且数据可流式处理，优先用
set+in；若还需保持顺序，不要先转set再排序，考虑dict.fromkeys(data).keys()（Python 3.7+ 保持插入序）
内存爆了怎么办？set 装不下 5000 万字符串
set 没有分片或懒加载机制，所有数据必须驻留内存。一旦触发系统 swap 或 OOM killer，程序直接崩溃。
- 先确认是不是真需要全量驻留：用
collections.Counter或numpy.unique（配合dtype='U100'）有时更省内存 - 替代方案（按优先级）：
- 用
bloomfilter（如pybloom_live）做存在性粗筛，再查磁盘/DB - 分块处理：读一批 → 去重 → 写临时文件 → 合并（用
heapq.merge配合已排序的临时文件） - 改用 SQLite 内存库：
con = sqlite3.connect(':memory:')建唯一索引表，INSERT OR IGNORE，对超大数据更稳
- 用
为什么 set.intersection() 在大数据量下反而慢？
a.intersection(b) 默认把小集合遍历、大集合查 hash，看似合理，但若两个集合都超千万，且元素 hash 冲突多（比如大量相似字符串），实际性能可能不如手动用 filter(lambda x: x in b, a)（后者至少避免构造新 set 的内存峰值）。
立即学习“Python免费学习笔记（深入）”；
- 关键点：
- 总是确保
len(a) 再调 <code>a.intersection(b) - 若只关心交集大小，用
sum(1 for x in a if x in b)可省掉结果 set 的内存分配 - 对字符串集合，提前用
sys.intern()减少重复对象，能显著降低 hash 冲突率和内存
- 总是确保
真正卡住的往往不是算法复杂度，而是哈希碰撞、内存分配延迟、字符串 intern 缺失这些细节。数据过亿前，先 sys.getsizeof(your_set) 看一眼实际占用，比盲目优化逻辑更有效。
