昨天 MySQL发布了个新版本V9.1.0，先看一下what‘s new里面写的东西。

1.Triggers no longer loaded by read-only operations。简单说，就是之前的版本，加载触发器的时候是直接解析的。现在优化为，只加载元数据，并不启动解析。
等表上有更新语句，要使用触发器逻辑的时候再解析触发器内容。
这样如果表上没有更新，比如还都是查询语句的时候，就不需要解析。

2. 优化了 explain的输出结果。explain_json_format_version=2的时候，多输出一个mrr信息；还调整了一些空格。

3.支持CREATE VIEW IF NOT EXISTS。
很早之前就支持CREATE Table  IF NOT EXISTS 和 Drop View if Exists。这回可算把这个语法给支持了。

4.Crash-safe database DDL statements。就是支持了create database 和 drop database的原子性。

5. VECTOR support in JavaScript programs. JavaScript 存储过程可以使用Vector类型的基本操作。 

6～N：其他的都是商业版的能力。

what's new 读后感：
1. 看到explain的输出结果的优化里“spaces have been added”的时候就想，实在没的写，要不就放着空？😓

2. Vector的那几个基本操作，在9.0的时候就是鸡肋。现在javascript存储过程能用了。然后Vector做了一点功能迭代，允许输入的字符串里有空格，然后解析过程中去掉空格。鸡肋撒孜然？😓😓

3. 其他社区版本的特性给人的感觉是，老板说一定要发个版本，new里实在没东西写，从闲置很久的待开发issue里，挑了几个好实现的凑个数😓😓😓

====乏善可陈的what's new  分割线 ====

新发布版本除了看new，就是看bugs了。

一般MySQL的bugs会同时在几个大版本里发布修复，我们切到关注8.0.40的bug列表。
这个版本有几个bug描述值得说说。

1. 如果有5.7版本下的表，包含了全文检索字段，并且以用户创建的FTS_DOC_ID列作为主键索引的，在升级到8.0.x版本时，可能导致升级过程进程异常退出。

这个bug本身都影响面不大，列出来是官方点名感谢了阿里数据库内核团队的huaxiong song同学。

2. 使用instant算法执行删除列操作后，马上执行delete或update语句，可能会导致进程异常退出。

3. 查询PS.DATA_LOCKS需要持有
locksys::Global_exclusive_latch和trx_sys->mutex两把大锁，可能会导致卡死业务SQL。

4. 有二级索引的表重建时，版本8.0.26之后有bug会导致InnoDB临时文件写盘量异常，进而导致DDL语句性能下降。

5. 对分区表做alter table会出错。

Bug 2～5都是影响面较大的，尤其是2和3，使用面积大，影响生产。
之前我写过一篇关于升级到8.0.x时有哪些小版本可以选的文章。
新发现的这些严重bug，会影响DBA对生产版本的选择。
比如使用分区表的业务，DBA就要选择绕开bug5.

后面我会再把认为严重的bug的引入版本和修复版本都确认一下发出来，提供避坑参考。

不过想来各个有提供云数据库服务的厂商也会关注的，毕竟提供服务给客户嘛。如果对上述bug的影响版本列表有明确结论，方便的话，也求分享哦。

====有一点慌的bugfix  分割线 ====

9.1里还有一个蛮有用的feature，就是增加了两个状态值，
TempTable_count_hit_max_ram 和 Count_hit_tmp_table_size ，
可以用来判断内存表转成磁盘表的时候，是因为全局内存不够，还是单个线程的tmp_table_size不够导致的。
上个月群里有个同学聊到线上的一个问题，还说到没法区分这两种情况。有这两个参数就能方便诊断了。

====哎呦不错的feture  分割线 ====

小结：其实大家现在都还在逐步升级到8.0，没人期待9.x这么快出来的，官方完全没必要操之过急，等憋点大招再发都可以的。

包括上次发布的9.0，这两个版本的功能，都作为8.0.x的一部分，也就差不多了，新开到9.x的版本里，给人感觉雷声大雨点小，没有必要。

==例行海报=本周六晚上直播《水平分库和分布式数据库》=