Laravel 向量搜索现已支持 MariaDB

Laravel 13 让开发者能够针对 MariaDB 执行原生向量搜索查询，在无需强制切换到 PostgreSQL 的情况下，为 Laravel 生态系统增加了语义搜索功能。

这项新支持取代了框架早期仅限 PostgreSQL 的实现，因此熟悉的 whereVectorSimilarTo 方法现在可以直接与 MariaDB 连接配合使用。如果你正在构建推荐引擎、文档相似度工具或任何依赖“最近邻”逻辑的功能，这一变化消除了一个主要的摩擦点。

为什么这一转变至关重要

Laravel 的查询构建器此前通过 instanceof 测试来检测向量搜索需求，而该测试仅能识别 PostgreSQL 连接。这种方法将该功能与单一驱动程序绑定在一起，并在代码库中充斥着特定于数据库的条件判断。

13 版本的发布将逻辑移入了语法层（grammar layer），并增加了两个特定于驱动程序的方法：

  • supportsVectorDistance() – 告知 Laravel 当前连接是否可以计算向量距离。
  • compileVectorDistanceExpression() – 构建执行计算的 SQL 片段。

通过将这些职责分配给每个驱动程序，框架摒弃了“类型检查”这种 hack 手段，并为未来的扩展扫清了障碍。现在，为另一个数据库添加支持意味着只需实现几个驱动程序方法，而无需到处散布条件块。

MariaDB 拥有原生函数，而 MySQL 则没有

MariaDB 自带原生向量函数。标准的 MySQL 则缺乏这些功能，除非你使用添加了 AI 扩展的专用云服务。

Laravel 有意避免在 PHP 端进行相似度计算。在 PHP 中计算向量会破坏分页功能，并在不发出警告的情况下降低应用速度。当驱动程序无法处理该操作时抛出错误，提供了一种更安全的失败模式。

MySQL 用户现在可以怎么做

如果你的技术栈运行的是纯 MySQL，你有三条切实可行的路径：

  1. 迁移到 MariaDB – 对于大多数 MySQL 工作负载来说，它是即插即用的替代方案，在保持相同生态系统的同时，为你提供原生向量支持。
  2. 添加专门的搜索服务 – 在 MySQL 旁边运行一个轻量级的 PostgreSQL 实例，专门用于相似度查询。
  3. 不使用它 – 对于许多应用来说，语义搜索是可选的；如果收益无法抵消运维成本，留在 MySQL 上可能是更务实的选择。

每个选项在运维复杂度、延迟和维护开销方面都存在权衡。决策取决于向量搜索在你的产品价值主张中的核心程度。

API 设计的启示

Laravel 的这一变化说明了一个更广泛的设计原则：避免在核心逻辑中到处散布特定于数据库的检查。当某个功能依赖于特定引擎的能力时，应将该依赖封装在驱动程序接口之后。新的基于语法的（grammar-based）方法正是这样做的，它为框架未来的扩展做好了准备，而无需重新改动核心查询构建器。

构建自己的扩展包的开发者应当注意。如果你在服务层发现了针对数据库类型的 instanceof 检查，请将该职责移交给驱动程序或专门的适配器。这能保持公共 API 的整洁，并让你的代码具备前瞻性。