前言
MySQL在本月发布了9.0大版本，作为一个老用户，忍不住关注了一下，简单说下这次大版本更新。
2023年，AI爆火，带动了向量数据库赛道。当下几乎所有主流 DBMS 都已经提供向量数据类型支持 —— MySQL 除外。
大家原本期待着在 9.0 创新版，向量支持能弥补一些缺憾，结果发布后等到的只有震撼 —— 竟然还可以这么糊弄？
向量Vector类型说说明
在 MySQL 9.0 的 官方文档上，只有三个关于向量类型的函数。抛开与字符串互转的两个，真正的功能函数就一个 VECTOR_DIM：返回向量的维度！（计算数组长度）
MySQL 9.0 支持 VECTOR 列类型。向量是一种数据结构，由条目列表（4 字节浮点值）组成，可以表示为二进制字符串值或列表格式的字符串。VECTOR 列声明有最大长度或条目数（在括号中）；默认值为 2048，最大值为 16383。
VECTOR_DIM()（也在 MySQL 9.0 中添加）返回向量的长度。提供了转换函数。STRING_TO_VECTOR()（别名：TO_VECTOR()）采用向量的列表格式表示并返回二进制字符串表示；VECTOR_TO_STRING()（别名：FROM_VECTOR()）执行相反的操作，如下所示：mysql> SELECT STRING_TO_VECTOR('[2, 3, 5, 7]'); +--------------------------------------------------------------------+ | STRING_TO_VECTOR('[2, 3, 5, 7]') |
+--------------------------------------------------------------------+| 0x00000040000040400000A0400000E040 | +--------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> SELECT VECTOR_TO_STRING(0x00000040000040400000A0400000E040); +------------------------------------------------------+| VECTOR_TO_STRING(0x00000040000040400000A0400000E040) | +------------------------------------------------------+
| [2.00000e+00,3.00000e+00,5.00000e+00,7.00000e+00] |
+------------------------------------------------------+
1 row in set (0.00 sec)
向量数据库的门槛不是一般的低 —— 有个向量距离度量函数就行（内积，10行C代码，小学生水平编程任务），这样可以通过全表扫描求距离 + ORDER BY d LIMIT n 实现向量检索，至少是个可用的状态。
但 MySQL 9 甚至连这样一个最基本的向量距离函数都懒得去实现，这绝对不是能力问题，而是 Oracle 根本就不想好好做 MySQL 了。老司机一眼就能看出这里的所谓 “向量类型” 不过是 BLOB 的别名 —— 它只管你写入二进制数据，压根不管用户怎么查找使用。最后交付个十分钟就能写完的东西糊弄了事。
不糊弄的例子可以参考 MySQL 的老对手 PostgreSQL。在过去一年中，PG 生态里就涌现出了至少六款向量数据库扩展（ pgvector，pgvector.rs，pg_embedding，latern，pase，pgvectorscale），并在你追我赶的赛马中卷出了新高度。最后的胜出者是 2021 年就出来的 pgvector[7] ，它在无数开发者、厂商、用户的共同努力下，站在 PostgreSQL 的肩膀上，很快便达到了许多专业向量数据库都无法企及的高度，甚至可以说凭借一己之力，干死了这个数据库细分领域
拿 pgvector 与来比似乎不太合适，因为 MySQL 9 所谓的“向量”，甚至都远远不如 1996 年 PG 诞生时自带的“多维数组类型” —— “至少它还有一大把数组函数，而不是只能求个数组长度”。
向量是新的JSON，然而向量数据库的宴席都已经散场了，MySQL 都还没来得及上桌 —— 它完美错过了下一个十年 AI 时代的增长动能，正如它在上一个十年里错过互联网时代的JSON文档数据库一样。
为 MySQL 提供矢量搜索
既然新版本如此拉胯，但是有数据基础设施现实存在，将其与现有数据基础设施集成可能是一个挑战。传统的 SQL 数据库（如 MySQL）虽然对结构化数据很强大，但难以处理向量数据和向量搜索操作的复杂性。
为了更好地理解这些挑战，让我们考虑一位电子商务开发人员的任务，他需要创建一个智能产品推荐系统，该系统根据与用户浏览和购买历史的语义关系来推荐产品。
为了实现这一点，开发人员通常会依赖 MySQL 之类的数据库系统来存储和检索必要的数据。但是，传统的 SQL 数据库并非设计用于高效处理向量搜索。幸运的是，有解决方案可用于在 MySQL 中启用向量搜索功能。
基本思路：MySQL数据库+矢量数据库
一种基本方法是维护两个独立的数据库——一个用于结构化产品数据和订单记录的 MySQL 存储库，而一个专用的向量数据库则存储产品描述的向量嵌入。为了提出建议，应用程序首先从向量数据库中检索并比较向量嵌入以识别相似的项目。之后，它会查询 MySQL 数据库以获取匹配产品的详细信息。这种方法可以比作同时驾驶两艘船——在充满挑战的语义复杂性浪潮中管理和传输它们之间的数据。
欢迎你分享你的作品到我们的平台上：www.shxcj.com 或者 www.2img.ai 让更多的人看到你的才华。
创作不易，觉得不错的话，点个赞吧！！！
