我刚在前文 MySQL 9.0发布，号称支持向量（Vector），但我却看不懂Oracle到底在玩什么 中吐槽 MySQL 9.0 手册和release notes里只字不提新增Vector（向量）数据类型及相关函数的事，后脚就被piapia打脸。
前文发完后，MySQL 官方徐老师（公众号：MySQL解决方案工程师）也证实了我的猜想：在 MySQL 9.0 里新增向量数据类型是为了 Heatwave 服务，而不是为了 MySQL 社区用户服务，使我以为他们也就没有更新相应配套的文档说明的计划。
蓝鹅，就在今天，MySQL 9.0 用户手册和 release notes 都“偷摸”更新了，加上了新增向量数据类型的相关说明：
Vector Data Type
-
Support is added in this release for a
VECTOR
column type. A vector is a data structure which consists of a list of entries (4-byte floating-point values) which can be expressed either as a binary string value or a list-formatted string. AVECTOR
column is declared with a maximum length or number of entries (in parentheses); the default is 2048, and the maximum is 16383. -
A
VECTOR
column cannot be used as any type of key. This includes primary keys, foreign keys, unique keys, and partitioning keys. -
Some types of MySQL functions and operators do not accept vectors as arguments. These include but are not limited to numeric functions and operators, temporal functions, full-text search functions, XML functions, bit functions, and JSON functions.
Some (but not all) string and encryption functions support
VECTOR
values. For more complete information, see VECTOR Supported and Unsupported Functions. -
A
VECTOR
cannot be compared with any other type, and can be compared with anotherVECTOR
only for equality. -
MLE JavaScript programs do not support
VECTOR
columns or values.
Oracle MySQL 这波实在令人看不懂了。
以 Oracle 财大气粗的揍性，还有基于以往对 MySQL 发版的管理节奏看，这些文档不应该是早就提前准备好了吗，好像 8.1、8.2 那次发新版本，还是先发布了文档后提供的下载包，为什么这次 9.0 却是反过来的，给我的感受就是肉眼可见的品控质量（或者说项目管理质量）严重下滑。说几个事佐证下吧。
-
芬达大师（公众号：芬达的学习笔记）最近报告了几个 Bug，但都被验证团队驳回，说无法复现之类的理由，从沟通记录来看，的确能感受到他们的傲慢和不在乎。想吃瓜的同学可以去问问芬达大师。
-
已有人提交了关于 MySQL 9.0.0 的 Bug，真是与时俱进啊。
-
前阵子 Percona CEO Peter 发文抱怨 Oracle 对 MySQL 最近几年的管理，可能是有意作恶或者说无知无畏，最终都可能会害死 MySQL（Is Oracle Finally Killing MySQL? 原文：https://www.percona.com/blog/is-oracle-finally-killing-mysql/）。文中的观点我也非常认同，对最近几年的 MySQL 发展真的是痛心疾首，Oracle 自从开始把重心转向云计算业务后，对 MySQL 这个重金（这笔钱对当时的 Oracle 似乎也只是毛毛雨）买来的小儿子看起来有点力不从心，或者说撒手放任不管？
-
Oracle 如果能再拿出刚接手 MySQL 时的产品规划力度，以及品控水平，那 MySQL 的未来前景肯定还是一片大好，否则的话，以往所有的荣光可能都会灰飞烟灭，不说被 PostgreSQL 超越，甚至有可能从此一蹶不振，堕入无底深渊。
-
昨天看到德哥发文预测 PostgreSQL 下个版本预计推出 64-bit XID，心想 PostgreSQL 就是因为缺乏强有力的商业公司领头，只靠社区用户用爱发电，其产品的项目管理和品控水平肯定不如 MySQL，但这次 MySQL 调整未来版本发布计划后，连续几次小乌龙，着实令人不爽，勉强可以自我安慰说是因为刚改成新的发版机制，所以还需要团队协作磨合吧，也希望的确是如此。
虽说今天吐槽了这么多，本意可以说是“深，责之切”爱之，作为多年的 MySQL 实名老铁粉，我肯定是希望 MySQL 能在未来能发展更好，重回巅峰，对此我很有信心。
Enjoy MySQL 🙂
《深入浅出MGR》视频课程
戳此小程序即可直达B站
https://www.bilibili.com/medialist/play/1363850082?business=space_collection&business_id=343928&desc=0
文章推荐：
-
MySQL 9.0发布，号称支持向量（Vector），但我却看不懂Oracle到底在玩什么
-
Slave SQL线程与PXB FTWRL死锁问题分析
-
GreatSQL统计信息维护管理
-
GreatSQL死锁案例分析及扩展解读
-
GreatSQL优化技巧：半连接（semijoin）优化
-
MySQL复制从库延迟优化思路
-
MySQL复制从库延迟原因深入分析
-
探究网络延迟对事务的影响
-
源码解析丨一次慢SQL排查之旅
-
面试题：INSERT...t...SELECT s会对s表加锁吗
-
被很多人忽视的NULL值对NOT IN子查询结果的影响问题
-
MySQL 8.0.26版本升级32版本查询数据为空的跟踪
-
SQL优化案例解析：MINUS改写为标量子查询后提升5倍，但还可以再快近百倍
-
关于GreatSQL字符集的总结
-
为什么SHOW TABLE STATUS显示Rows少了40%
-
MTS性能监控你知道多少
-
MySQL对derived table的优化处理与使用限制
-
MySQL一次大量内存消耗的跟踪
题图由阿里通义万相生成
提示词：堕落天使
想看更多技术好文，点个“在看”吧
