一条SQL完成分子对接，DuckDB化学扩展实测
alitrack约 5 分钟分子对接，一直是专业软件的地盘。AutoDock、GOLD 这类工具装起来就不轻，配受体、写脚本、跑打分，一套流程下来半天没了。现在这件事可以一条 SQL 完成。
DuckDB 的社区扩展 ducksmiles，把整条经典 CADD（计算机辅助药物设计）管线装进了数据库：读分子、算描述符、查子结构、过滤毒警示，直到分子对接打分，全程不离开 SQL。
本文不只转述官方文档。所有函数我都在本机跑了一遍，还做了三方性能基准，文末有真相。
● ● ●
一个扩展，装下一条 CADD 管线
先看安装，两行 SQL：
INSTALL ducksmiles FROM community;
LOAD ducksmiles;
ducksmiles 是纯 Rust 实现，零外部化学库依赖，不要求你装 RDKit。官方数字是 435 个 SQL 函数，其中 156 个分子函数、279 个 CPU 分析函数。兼容 DuckDB 1.4.4 到 2.0.0 的主流版本。
按一条虚拟筛选的典型流程，看它每一步都覆盖了什么。
第一步，读分子。 SMILES、InChI、MOL/SDF（V2000/V3000）、PDB、mmCIF、XYZ、SELFIES，常用格式全部支持双向转换。你的化合物库是 SDF 也好 Parquet 也好，进了 DuckDB 就是表。
第二步，算性质。 分子量、Wildman-Crippen LogP、摩尔折射率、拓扑极性表面积 TPSA、QED 成药性指数、Lipinski 全家（氢键供受体/可旋转键/杂原子/环系）。这些描述符是 RDKit 的忠实移植，官方用锁定版本 RDKit 2025.09.6 的参考套件跑过 4510 个输入的比对验证。
第三步，查结构。 SMARTS 子结构匹配、Bemis-Murcko 骨架提取、骨架网络、环系统分析、最大公共子结构 MCS、MolHash 标准化。指纹有 Morgan（默认半径 2、2048 位）和 MACCS（167 位），相似度度量 11 种，从 Tanimoto 到带权重的 Tversky。
第四步，过滤。 六套成药性规则面板（Lipinski/Veber/Ghose/Egan/Muegge/Lead），加一个 Brenk + PAINS 毒性警示目录。PAINS 那些偏爱造假的杂环_warned 结构，一条 SQL 就标出来了。
第五步，对接。 这是它最出格的部分，下一节单独说。
● ● ●
对接三件套，全在 SQL 里：
-- 配体准备：SMILES 转 PDBQT（距离几何 3D 构象 + 力场最小化）
SELECT smiles_to_pdbqt('CC(=O)Oc1ccccc1C(=O)O');
-- 受体准备：pH 依赖质子化 + 极性氢
SELECT prepare_receptor(:pdb, 7.4);
-- 对接：柔性扭转树 + AutoDock-Vina 风格打分，返回排序 pose
SELECT dock('CCO', :receptor_pdb, 1.0, 0.5, 0.0, 8, 8, 8, 20, 42);
我在本机跑通了 dock()。给乙醇分子和一个四原子的小肽受体做对接，五行参数指定盒子中心和尺寸，返回 JSON：5 个 run，最好 pose 打分 -0.369，九个原子的三维坐标完整输出。
打个预防针：打分函数是 AutoDock-Vina「风格」（Vina-style scoring），不是 Vina 本体。我的冒烟测试用的是小肽，不是真实蛋白靶点。「能跑通」和「能替代专业对接软件」是两回事，精度对标本文没测，不装。
但「能跑通」本身就是新闻。以前要把分子库挨个喂给外部对接软件再收结果，现在库在 DuckDB 里，对接就是表上的一个函数调用。配合 roc_auc、enrichment_factor、bedroc 这三个虚筛富集指标（也内置了），一条查询就能做完「筛完打分、评富集」的闭环。
● ● ●
基准：能跑，但别拿它批量算描述符
光看功能清单会以为可以全押给它。我做了个三方基准，同机同日：
10 万个类药分子（模板枚举生成，Parquet 列存），每个算 3 个描述符（分子量、LogP、TPSA），三种引擎跑同一份数据：
结果有点意外：纯 Rust 的 ducksmiles 反而最慢，比 Python 手写 RDKit 循环慢 6 倍多。duckdb_rdkit（RDKit 官方 C++ 绑定的另一个扩展）居中，比 Python 慢一半。
这说明 ducksmiles 的描述符函数没有走向量化批量路径，逐行调用的开销吃掉了 Rust 的优势。官方文档也确实只承诺「RDKit 忠实移植」，没承诺批量性能。
务实的选择是组合用：批量算描述符、跑相似度检索，用 duckdb_rdkit；要 PAINS 过滤、骨架分析、MCS、对接这些 duckdb_rdkit 没有的能力，再 LOAD ducksmiles。两个扩展可以共存，谁擅长什么用什么。
（基准口径说明：单机 WSL 环境，DuckDB 1.5.5，rdkit 2026.09.1，单次快测，不是审计级基准。）
● ● ●
化学扩展不止这一个
顺手把 DuckDB 社区扩展列表里的「大健康」板块过了一遍，这个生态比想象中热闹：
duckdb_rdkit：RDKit 绑定版，描述符/子结构/指纹 ducksmiles：本文主角，纯 Rust 全家桶 mmcif：蛋白结构 mmCIF 文件读写 miint：微生物组（FASTQ/SAM/BAM/BIOM/GFF/Newick） plinking_duck：PLINK 2 基因组学格式与分析 dicom：医学影像 DICOM
没有的东西也列一下：AI 分子生成（DiffSBDD、DrugFlow 这类扩散模型）、分子动力学模拟、自由能微扰计算。这些重计算活在 SQL 形态里本来就不合适，通用 ML 扩展（ml、mlpack、表格基础模型）也替代不了药物专用模型。经典 CADD 层面数据库已经够到了，AI 设计层面还是 Python 引擎的地盘。
● ● ●
这件事的真正意义
对写 SQL 的数据工程师，分子数据从此不是特殊公民：化合物库就躺在 Parquet 里，描述符是对账般的列操作，毒警示过滤是 WHERE 子句。
对做药物发现的人，门槛降了一大截。不必为了筛 10 万个分子去装一整套 RDKit 环境、学 Python 脚本，一个 DuckDB 二进制加一行 INSTALL，熟悉的 SELECT 语法就够。
对工作流引擎和可视化编排工具的作者，这批化学扩展是现成的弹药库。引擎只要能加载 DuckDB 扩展，化学能力就是白捡的，节点编排的价值回到「把流程拼起来」本身。
一条 SQL 完成分子对接，这事成真了。快慢的真相、边界的真相，也都摆在这了。
参考来源：
ducksmiles 官方文档：https://duckdb.org/community_extensions/extensions/ducksmiles DuckDB 社区扩展列表：https://duckdb.org/community_extensions/list_of_extensions duckdb_rdkit：https://duckdb.org/community_extensions/extensions/duckdb_rdkit 本文基准数据与实测脚本已随私有仓存档（含 100k 分子数据集、三方基准脚本、对接冒烟测试记录）