MoteDB v0.16.0 发布：28 轮系统性猎虫，42 个缺陷修复（含 1 个数据损坏级）—— 一个 Rust 写的 AI 原生嵌入式多模态数据库
内容提要
MoteDB 是纯 Rust 编写的嵌入式多模态数据库，面向具身智能，支持向量、全文、时序、空间索引及 SQL 与 ACID 事务。v0.16.0 经 28 轮系统排查修复 42 个缺陷，重点解决静默错误，包括向量列合并后数据损坏、未知列被静默忽略、中文全文检索恒空、同义写法结果不一致等。四层 API 端到端验证通过，性能无回归，并公开已知限制。
延伸解读
静默错误：数据库最危险的缺陷类型
文章指出，不报错却返回错误结果的“静默错误”比程序崩溃更危险。v0.16.0 修复的 42 个缺陷中，多个属于此类：向量列合并后读成全零向量、WHERE 未知列被静默忽略、中文全文检索恒空。这些错误不会中断程序，却可能让上层应用基于错误数据做出决策，排查成本极高。对使用嵌入式数据库的开发者而言，这意味着升级后应重点验证涉及向量更新、拼写错误列名和中文检索的场景。
中文检索从“恒空”到可用：分词策略的转变
此前 MoteDB 的全文索引和逐行 MATCH 都硬编码空白分词器，无空格的中文句子会被当作一个整 token，导致 MATCH(body) AGAINST('训练') 在“深度学习模型训练”上两条路径均返回空。v0.16.0 默认启用 AutoTokenizer：含 CJK 字符时走 jieba 精确分词，其余仍用空白分词，且索引与逐行路径共用同一套逻辑。对中文用户来说，这解决了检索功能实际不可用的问题，但分词效果仍取决于 jieba 的词典覆盖。
修复背后的工程教训：双实现与占位字节
文章总结了两条对 Rust 开发者有参考价值的教训。一是“双实现必漂移”：时间戳解析器和算术求值器各有 SqlRow 与 positional 两份副本，修了一份忘了另一份，导致小数秒丢弃、类型分支缺失等问题。二是“占位字节也要过编码学”：合并时墓碑行的占位符本意是“没人读”，但在变长编码里任何字节序列都是合法数据，0xFFFF 被解码为合法维度后引发雪崩式错位。这提醒开发者，宽度正确不等于语义正确。
发布质量与已知限制：升级前需权衡
v0.16.0 在四层 API（Rust、Node、Go、Python + MCP）上做了端到端验证，Rust 侧有 292 个测试二进制、4253 条断言；与 9 个版本前背靠背对照，ORDER BY 快约 28%、查询内存省 18%，点读、扫描、GROUP BY 持平。但文章也公开了已知限制：WHERE 中的除零错误目前会被吞掉（在路线图中）、列级 UNIQUE 约束未实现、Windows npm 二进制因 npm 反垃圾误伤暂缺。升级前应确认这些限制是否影响自身业务。
Q&A
MoteDB 是什么数据库？主要用在哪些场景？
MoteDB 是一个纯 Rust 编写的嵌入式多模态数据库，面向具身智能场景（如机器人、AR、边缘设备）。它支持向量、全文、时序、空间四类索引，并具备列存、ACID 事务和 SQL 能力，单进程嵌入式运行，无外部依赖，采用 MIT 协议，可通过 cargo add motedb 直接使用。
v0.16.0 版本主要做了什么？修复了多少缺陷？
v0.16.0 是一个专注于找 bug 的版本，发布前进行了 28 轮系统性猎虫，累计修复 42 个缺陷，重点解决静默错误结果类问题，而非增加新功能。
向量列在 UPDATE + DELETE + 段合并后读成 65535 维全零向量是怎么回事？
这是一个数据损坏级 bug：列段合并时，墓碑行的占位字节给 VECTOR 列写的是裸 [0xFF 0xFF]，而在逐行 [dim: u16][payload] 编码中 0xFFFF 是合法的非空维度，但后面没有实际载荷，导致顺序解码器从该行开始错位，同列后续行雪崩（实测 80 行的表有 17 行损坏）。修复方式是将占位改为 [0x0000]（dim 0 表示 NULL）。
WHERE 条件里写了不存在的列名为什么没有报错？现在修复了吗？
之前 WHERE 未知列会被静默吞掉，返回 0 行且无报错，因为逐行过滤路径出于性能将求值错误统一视为不匹配。修复方式是在语句入口做一次 schema 绑定校验。但为避免动态回退失效，JOIN 和相关子查询豁免此校验。
中文全文检索为什么之前总是查不到结果？现在怎么解决的？
之前 FTS 索引和逐行 MATCH 都硬编码空白分词器，无空格的中文句子会被当成一个整 token，导致 MATCH(body) AGAINST('训练') 匹配不到“深度学习模型训练”。现在默认使用 AutoTokenizer：含 CJK 字符时走 jieba 精确分词，其余情况用空白分词，索引与逐行路径共用同一分词器。
v0.16.0 在发布工程质量方面做了哪些验证？
四层 API（Rust、Node、Go、Python + MCP stdio 协议）全部在当前引擎上端到端验证；性能 A/B 无回归，与 9 个版本前背靠背对照，ORDER BY 快约 28%、查询内存省 18%，点读/扫描/GROUP BY 持平；clippy 双 feature 集零警告；语义行为（除零、LIKE 大小写、复合主键等）全部钉住并写入文档。
