1. BLAST 工具概述与内存问题背景

1.1 先聊聊 BLAST 到底在干什么

BLAST，全称 Basic Local Alignment Search Tool。说白了，就是一个在巨大序列库里快速找相似片段的工具。

我最初接触它是在做基因组注释的时候，要拿一条未知的 cDNA 去跟参考基因组比对。当时我还在想，这工具怎么这么慢？后来才算明白——它并不是慢，而是它干的活儿本身就重。

它的核心思想很简单：

• 建索引：把数据库里的序列切成小块（k-mer），做成哈希表或查找树
• 找种子：用查询序列的小片段去索引里快速匹配
• 延伸比对：从种子向两边扩展，用动态规划做精确对齐
• 打分输出：按 E-value 和分数排个序，输出给用户

你想想看，这里面每一步都跟内存密切相关。索引的大小、种子的存储、延伸时 Smith-Waterman 要的矩阵，全在吃内存。

1.2 为什么老是内存超限？

我记得有一次，实验室的同事跑 BLASTX（把核酸翻译成蛋白再比对），拿了个 10 万条序列的查询文件，去比对 NR 库。服务器 64GB 内存，直接挂掉了。

他来找我帮忙，我看了眼日志：

BLAST Engine error: Cannot allocate memory
BLAST query/query batch size out of range

原因其实很典型——

1. 数据库太大：NR 库压缩后几十 GB，解压后更大，BLAST 默认会把整个索引读到内存里
2. 查询文件太大：一次性加载多条长序列，内存瞬间被撑爆
3. 输出格式复杂：XML 格式结果比文本格式多占用 3-5 倍的内存
4. 线程并发：默认用多线程时，每个线程都有一份重复的数据结构

为什么会这样？因为 BLAST 设计之初，大家都觉得内存不值钱。现在呢？动辄全基因组、全转录组，NR 库都几百 GB 了，老版本的 BLAST 真的顶不住。

1.3 内存问题的两个维度

我做性能分析时习惯把内存问题分成两类：

分类	典型现象	常见原因	发生率
内存溢出	进程被 OOM killer 杀死，日志报 Cannot allocate memory	数据库过大、查询批次过大、多线程重复分配	★★★★★
内存碎片	系统还有内存，但 BLAST 频繁报错新分配失败	多次重复调用的累积、大块分配后释放不完全	★★★☆☆

其实大多数情况是第一种，内存溢出。但我在生产环境见过第二种，跑连续批量比对时，越到后面越慢，最后卡死。检查发现是内存碎片导致分配效率下降。

1.4 BLAST 各变种的内存消耗差异

BLAST 家族有很多成员，内存开销天差地别。我整理了一下：

程序	比对类型	索引大小（参考）	单查询峰值	典型应用
blastn	核酸 vs 核酸	中等	较低	短读比对、引物验证
blastp	蛋白 vs 蛋白	较低	中等	功能注释
blastx	核酸翻译 vs 蛋白	蛋白库索引	高	转录组比对到蛋白库
tblastn	蛋白 vs 核酸翻译	核酸库索引	最高	跨物种同源搜索
psiblast	迭代蛋白比对	蛋白库索引	逐步增长	远源同源检测

你猜哪个最容易踩内存坑？我个人经验是 blastx 和 psiblast。前者因为要把核酸翻译成 6 种蛋白框架，种子数和延伸次数暴增；后者因为迭代过程中序列会累积，内存越吃越多。

1.5 一个典型的内存超限场景

我举个例子，你感受一下：

# 一条典型的 BLASTX 命令
blastx -query transcriptome.fasta \
       -db nr \
       -out result.xml \
       -outfmt 5 \
       -num_threads 16 \
       -max_target_seqs 500

这个命令有 4 个潜在内存杀手：

• query transcriptome.fasta：转录组文件可能几百 MB，BLAST 默认全读
• -db nr：NR 库索引压缩后 30-50 GB
• -outfmt 5：XML 格式，内存占用是默认文本格式的 3 倍
• -num_threads 16：16 线程，每个线程的临时数据重复 16 份

我在项目里遇到过，用户跑类似的命令，128GB 的内存都不够用。解决方案我们后面章节会详细讲，但提前说一句核心思路：别让 BLAST 一次性处理所有数据。

1.6 本章核心知识图谱

下面这张图概括了 BLAST 内存问题的全貌。你可以把它当作战术地图：

这张图把核心问题拆成了 内存溢出 和 内存碎片 两条线。左边是数据库索引和查询批次问题，右边是多线程和反复加载问题。下面的解决方案我们会一步步展开。

1.7 小结：为什么要先从背景讲起？

我讲课的习惯是，先搞清楚问题的全貌再动手。内存超限不是单一原因，你上来就改参数，可能越改越糟。

记住三个核心原则：

• 先诊断，再用药：搞清楚是索引问题还是查询问题
• 从小处试：用一小部分数据测试参数调优效果
• 监控要比对更早：跑之前打开 top 或 htop，观察内存走势

我曾经有个项目，代码调了两天都没搞定，最后发现是数据库索引文件被损坏，BLAST 重复加载失败导致内存泄漏。嗯，从那以后，我每次跑比对之前都会先检查索引完整性。