第4章 数据库构建：makeblastdb命令与常用参数归纳总结
说实话，makeblastdb这条命令，在我刚入行那会儿完全没当回事儿。总觉得生物信息学嘛，处理数据才是重头戏，建个索引库而已，没什么技术含量。直到有一次，同事跑了个BLASTP，结果出来一堆垃圾——后来一查，发现是构建数据库时把序列类型设成了核苷酸……
嗯，从那以后，我再也不敢小看这一步了。今天我就带你捋一捋makeblastdb的常用参数，顺便聊聊我踩过的坑。
命令基本格式
先看最核心的调用方式：
makeblastdb -in input.fasta -dbtype prot -out my_db这行命令的意思是：拿input.fasta里的蛋白质序列，建一个叫my_db的BLAST数据库。-dbtype prot指定序列类型是蛋白质。
我个人习惯把-out参数写得跟项目名一样，比如lncrna_human_v1。这样后续搜索时一目了然，不容易搞混。
参数分类：核心参数 vs 可选参数
我把常用的参数归了个类，写了个表格，你留着当参考。项目里照着它选参数，基本不会出错。
| 分类 | 参数名 | 缩写 | 默认值 | 说明 |
|---|---|---|---|---|
| 基础参数 | -in |
无 | 无（必填） | 输入的FASTA文件路径 |
-dbtype |
-d |
prot |
序列类型：prot（蛋白质）或nucl（核酸） |
|
-out |
-o |
输入文件名（无扩展名） | 数据库前缀名 | |
| 序列源参数 | -title |
-t |
输入文件名 | 为数据库设置一个可读的标题 |
-parse_seqids |
-parse |
关闭 | 解析FASTA标题中的序列ID | |
-hash_index |
-hash |
关闭 | 创建哈希索引（用于快速检索序列ID） | |
| 分卷与大小 | -max_file_sz |
-max |
4 GB | 每个卷文件的最大字节数 |
-logfile |
-log |
标准错误输出 | 将日志写入指定文件 | |
| 性能与附加 | -mask_data |
-mask |
无 | 为数据库预加载一个掩码文件（如低复杂度区域） |
-gi_mask |
无 | 无 | 基于GI号指定掩码 |
核心参数详解
-dbtype: 数据库类型
这是最容易出错的参数，没有之一。prot和nucl写反了，后续所有BLAST结果全是错的。
我曾经接手过一批数据，对方建库时用了 -dbtype nucl 但实际序列是蛋白质。结果BLASTX跑出来的比对完全无法解释。浪费了两天时间排查。从那以后，每次建库前我都会先看一眼FASTA文件的序列组成：蛋白质序列是单字母氨基酸（A、V、L……），核酸是ATCG。简单看一眼就行，千万别偷懒。
-parse_seqids: 序列ID解析
这个参数我建议每次都加上，哪怕你觉得用不上。如果你不加，BLAST输出的结果里序列ID会变成类似gnl|BL_ORD_ID|123这种丑到爆的形式。加了之后，结果里会直接显示FASTA文件中自定义的序列标签，比如lcl|gene_001。
你想想看，后面做注释一致性检查时，如果序列ID不可读，那批处理脚本得多难受？我习惯在脚本里直接写：
makeblastdb -in query.fasta -dbtype prot -out my_db -parse_seqids多写一个参数，省心一辈子。
-max_file_sz: 分卷大小
基因组级别的序列，构建出来的数据库动不动几十GB。如果不设分卷，单文件会撑爆文件系统限制（尤其是老旧的NFS环境）。我个人习惯设成2GB：
makeblastdb -in genome.fasta -dbtype nucl -out genome_db -max_file_sz "2GB"注意参数值要用双引号括起来，否则可能被shell解释成数字加“GB”的乱码。我见过有人写2GB不带引号，结果建出的库全是0字节的文件。
-logfile: 日志与错误输出
建议重定向到文件，不要依赖屏幕输出。尤其当数据库规模大、构建时间长时，屏幕缓冲可能爆掉，导致你什么日志都看不到。
makeblastdb -in huge.fasta -dbtype prot -out huge_db -logfile makeblastdb.log跑完之后，makeblastdb.log会记录完整过程。你可以在里面检索Error或Warning关键词，快速定位问题。
我的个人参数模板
每次做批次注释一致性检查时，我都用一种固定模板来构建数据库，省得失焦：
makeblastdb \
-in batch_annotations.fasta \
-dbtype prot \
-out project_v1 \
-parse_seqids \
-title "Batch Annotation Check v1" \
-logfile build_db.log \
-max_file_sz "2GB"不加mask_data和hash_index，是因为检查注释一致性时，我们一般不需要低复杂度掩码，而且批处理查询的次数没那么多，索引的收益不高。
常见避坑清单
- 序列类型写错：
-dbtype prot写成了-dbtype nucl或反过来。 - 不加
-parse_seqids：结果中的序列ID变得不可读，后续批处理脚本没法用。 - 不分卷：大数据库文件超过4GB，可能在老旧文件系统上读写失败。
- 日志不保存：报错了没地方看。
- 输入FASTA文件中的序列ID重复：
makeblastdb不会报错，但重复ID可能导致查询结果混乱。
一句话总结：建库不是小事。参数选对，后续所有分析都顺畅；参数选错，你连排查的方向都找不到。每次写命令前，问自己三个问题：序列类型对了吗？序列ID解析加了吗？文件系统够用吗？
上面这张图展示了我建库时的完整流程。从输入序列开始，到核心参数设定，再到索引构建和输出，最后进入BLAST查询阶段。如果你按照这个流程写脚本，既干净又不容易出错。