MySQL 9.0 的 VECTOR 类型仅是带长度校验的二进制容器，不支持距离计算、索引或 ORDER BY 距离排序；真正向量检索需依赖 PolarDB 或 AnalyticDB 等云服务，或用 FLOAT 列模拟。
MySQL 9.0 的 VECTOR 类型本身不支持向量检索——它只是个带长度约束的二进制容器，没有距离函数、没有索引支持、不能 ORDER BY ... DISTANCE。所谓“支持向量检索”，必须依赖外部扩展或换用兼容 MySQL 协议但真正实现 ANN 的替代方案。
别被 VECTOR 类型误导：它不是向量数据库
MySQL 9.0 的 VECTOR(n) 列类型本质是带校验的 BLOB：
- 只做维度合法性检查（如
VECTOR(16384)直接报错ERROR 9040），不校验浮点值范围或 NaN -
STRING_TO_VECTOR()和VECTOR_TO_STRING()仅做字符串 ↔ 二进制转换，无语义解析 - 没有内建的余弦/欧氏距离函数，
SELECT * FROM t ORDER BY vec_col <-> ? LIMIT 10会语法报错 - 无法在
VECTOR列上创建有效索引；InnoDB 不识别该类型为可索引字段
真能跑向量检索的 MySQL 生态选项
如果你坚持用 MySQL 协议 + 向量能力，有且只有以下两类实际可用路径：
-
PolarDB MySQL 版（8.0.2.2.27+）：阿里云提供原生
VECTOR类型 +HNSW索引 +<->距离操作符，语法完全兼容 MySQL 9.0 定义，但底层是自研向量化执行引擎 -
AnalyticDB MySQL 版：支持
VECTOR列 +ANN检索 + 结构化过滤融合（如WHERE category='tech' AND vec_col <-> ? < 0.3），PB 级数据实测 99.5% 召回率 - 注意：二者均为云服务，无开源单机版；本地部署只能选 PolarDB 的私有化版本（需商务授权）
本地快速验证：用 FLOAT 列模拟向量 + 全表扫描
若仅需 PoC 验证 RAG 流程（非生产），可绕过 VECTOR 类型，用传统列存：
- 创建 512 列
FLOAT（如v1~v512），配合GENERATED COLUMN计算欧氏距离（MySQL 8.0.17+ 支持） - 写入时用应用层将 embedding 数组展开为 512 个值，避免 JSON 解析开销
- 查询时用
ORDER BY SQRT(POW(v1-?,2)+POW(v2-?,2)+...)手动算距离 —— 数据量 ≤ 10 万行时响应尚可（实测 8600 万行需 1.2s） - 加
INDEX(v1,v2,...,v512)无效，MySQL 不支持多列前缀索引用于距离计算
最容易踩的坑：混淆“能存”和“能查”
很多人装完 MySQL 9.0 就立刻 CREATE TABLE t (id INT, v VECTOR(1536));，然后卡在下一步：
- 试图用
WHERE v = STRING_TO_VECTOR('[...]')——VECTOR不支持等值比较以外的任何运算 - 执行
ALTER TABLE t ADD INDEX idx_v(v)—— 报错ERROR 1178：“The storage engine for the table doesn't support vector column indexing” - 查文档找
COSINE_DISTANCE()函数 —— 官方文档里根本不存在，所有距离函数都是社区魔改或云厂商私有实现
真正能落地的向量检索，从来不是靠“最新版 MySQL 自带功能”，而是选对带 ANN 引擎的兼容层。MySQL 9.0 的 VECTOR 类型目前唯一确定用途，就是作为 embedding 的标准化存储容器——查，得靠外面套一层。
