• 近期,据可靠的非正式消息,MySQL可能很快会发布新的版本管理模式:通过长期稳定版(Long-term Support)和短期创新版本(Innovation Releases)的方式进行管理。如果采用这种模式,将会更加有利于新特性新功能的引入,同时保持LTS的长期处于较稳定的状态(可以参考ClickHouse的版本管理现状),缺点则是版本会非常多,对新手不是那么友好。另外,因为MySQL 5.7的生命周期将于今年10月正式结束,如果届时依旧没有新的版本的话,MySQL 8.0就会是唯一的稳定版,通常对于快速发展的开源软件来说,这并不健康。所以,前述的消息虽然是非正式的,但是相信是非常可靠的。那么新的版本是号会是8.1、9.0、或者23、2023,拭目以待。

    本文总结了过去20年,MySQL的版本发展历史,回顾一下其重大功能发布的情况,以及大版本发布的节奏。

    (more…)
  • 重要更新

    TiDB x CAPCOM丨为在线游戏提供灵活、可靠、可扩展的数据库服务:链接。该案例最早于去年7月对外发布(参考),CAPCOM是老牌日本游戏厂商,其经典黄色logo承载了一代代游戏人的记忆,而TiDB进入CAPCOM也代表中国数据库厂商征战全球数据库领域的取得成果,加油!

    TDSQL落地湖州银行新核心系统:该行基于TDSQL建设新核心系统,系统包含众多应用于业务,整体上,提升了客户体验,同时系统灾备恢复时间接近于零,业务处理能力提升10倍以上:链接

    原阿里云OLTP和 NoSQL数据库产品总负责人曹伟(花名:鸣嵩)创立的云猿生数据公司正逐步浮出水面:参考1。曹伟曾担任阿里云数据库负责人、也是PolarDB产品创始人,其创业产品也非常让人期待。

    更新详情

    腾讯云RDS MySQL
    • RDS MySQL 支持创建跨可用区 RO,进一步提升数据容灾能力:链接
    • TDSQL-C MySQL 发布数据库代理功能,支持自动读写分离、事务拆分、连接池、防闪断等功能:链接
    阿里云
    • PolarDB-X发布5.4.17版,提供了生成列、函数索引、默认秒级加字段、显示与隐藏索引等功能:参考
    AWS
    • MemoryDB for Redis 开始支持Redis 7: 链接;支持了 IAM 身份验证: 链接
    • Redshift 数据共享功能开始支持中国地区:链接
    • Aurora Serverless v2 新增四个地区支持,包括亚太(海得拉巴)、西班牙、苏黎世和阿联酋:链接
    GCP
    • Spanner审计日志新增了请求数据时间记录:链接
    • BigQuery优化了外部数据源(Cloud SQL或Spanner)下推能力:链接
    • AlloyDB新增了更多区域支持,包括德里、马德里、荷兰、米兰、特拉维夫、蒙特利、多伦多、巴西、圣地亚哥等:链接

    推荐阅读

    • 国有大行,全面开花 | TDSQL inside:链接
    • 浙江首例!国产分布式数据库落地湖州银行新核心系统 | TDSQL inside:链接
    • 平凯星辰中标建设银行国产数据库小机下移项目:链接
    • 帮你了解一下GaussDB:链接
    • 中国联通数据库实践:CUDB for OceanBase分布式数据库产品规模应用:链接
    • 数据库内核那些事|分布式数据库,挂掉两台机器会发生什么?链接
    • 使用AI优化慢SQL,开发秒变DBA:链接
    • 什么是矢量数据库:链接
    • AI大模型与向量数据库 PGVECTOR:链接
    • 16年等待,再见 SQL Boy,这一次数据库交互形态彻底被颠覆了!:链接
    • 国产数据库“开源套壳”是否可取?链接
    • 今天,Nintendo《塞尔达传说–王国之泪》正式发售。根据Nintendo官网招聘信息,其主要使用了MySQL、PostgreSQL、Redis等数据,根据AWS官网的Nintendo的客户案例来看,该公司还使用Aurora(MySQL兼容)
  • 当我们乘着缆车,看着两边的绝壁上屹立着众多挺拔的“黄山松”;当我们来到玉屏楼后,看到立仞千米的山峰;当风来雾散时,看到神奇而孤独的小“猴子”;当站在迎客松前,想到它挺拔于此千年。人群的喧闹,而数亿年来山峰从不言语,只是静静伫立,一时让人恍惚,到底是谁在看着谁?

    也早就听说过:“五岳归来不看山,黄山归来不看岳”,也在孩子的课本上看到过各式各样“黄山奇石”、黄山奇松”。而当所有的一切呈现在眼前时,给内心的震撼是巨大的,一面感叹,徐霞客诚不欺我,一面再一次理解“纸上得来终觉浅,绝知此事要躬行”。

    当我们爬到迎客松所在处,抬头,左侧是天都峰,右侧是黄山最高峰–莲花峰,背后是玉屏楼。山峰立仞千米,平滑处可竖立百米而鲜有植被,山顶多有造型各异的奇石。恰如徐霞客所言:“左天都,右莲花,背倚玉屏风,两峰秀色,俱可手擥。四顾奇峰错列,众壑纵横,真黄山绝胜处”。

    雾中黄山

    到达黄山的第二天,已经是绵绵的阴雨天,这大概是登黄山最让人担心的了。因为黄山的奇、秀都在远处的山中,在阴雨天会升起大雾,能见度很低,几乎什么景色都看不大。因为是早就安排好的行程,定好的酒店也无法变更,只能按原计划登山,缘分观看各处景色。

    一早约六点,我就和大娃起床,再次来到酒店门口的迎客松,此时已是大雾锁山,好在迎客松就在近处,虽是朦胧,但依旧可以看得清晰。

    离开玉屏楼,按行程,我们就向光明顶方向走去,经过莲花亭,再过鳌鱼峰,抵达白云宾馆处,再取到西边,体验了一下西海大峡谷的“网红”小火车,但因为云雾缭绕的缘故,并没有看到好的效果。再向前,就是光明顶了,据导游介绍这里是观看日出、日落最好的地方,也是能够尽收半个黄山美景之处,只是也因为大雾,几乎什么都看不到。再继续向西,经过黑虎松,很快就到达了第二天入住的酒店狮林大酒店。稍作修整,期待接下来能够天气转好。

    三寻“猴子观海”

    大概是海拔高的原因,黄山的天气有一些变幻莫测。我们第一日去晴天,次日入住狮林大酒店后,天气就开始持续的小雨,整个黄山就笼罩在或薄或厚的雾气之中。“猴子观海”最佳观赏点就在酒店旁边约十五分钟登顶的一个小山峰之上。当天晚上,搬完入住之后,外面一直在淅淅沥沥的下着一些小雨,到傍晚约6点左右,雨虽然停了,但是雾气一直没散,听酒店工作人员说,这样的雾气下是很难看到“猴子观海”的。不过,如果运气好的话,一阵大风过来,雾气吹散开,也能看到。这时候,就有一些担心,这次可能会看不到这个著名的景点了。

    吃晚饭的时候,kiki说想一个人出去探探,半小时后回来,兴奋的跟我们说,大雾散开了一会儿,大概也就30分钟,恰好看到了传说中的猴子观海。我本想也立刻去看看,但此时,天已经黑了,加之大雾再起,所以今天已经看不到了。看着她拍的视频和照片,希望明天能够亲眼看看。后来,听酒店的人说,今天一整天,只有那大概30分钟能够看到“猴子观海”,今天能够看到,实属机缘。

    次日清晨,起床第一件事,就是拉开窗帘看看外面的雨雾是否消散,看起来雾气似乎比昨天要小一些,于是,一早就带着大娃向山上出发,来到一处观景台,一眼望去尽是大雾,虽然风来会隐隐消散一点,但是能见度依旧很低,什么多看不到。于是,只能带着大娃败兴而归。

    到了上午,雾气似乎又散去了一些。kiki大概看出来,我对“猴子观海”似乎有一些执着,于是带着我,说再去碰碰运气。走到半路,kiki看着山中大雾就说,这大概也是什么都看不到的。不过,我俩还是决心上到观景台再说。这时,路上还会时不时遇到行人从上面下来,都说什么都看不到。这时,心里也已经不抱希望了。来到山顶,果然,大雾没有让我们“意外”,依旧是什么都没看到。不过,这次好在把地方了解准确了。原来,早上我和大娃所到之处,还没有到真正的“猴子观海”观景台,是还需要再向上爬五分钟的。虽是大雾,还是在那里拍了一张“猴子观海”。

    等了大概十来分钟,大雾始终没有消散,只能下山。当走到“麒麟松”所在处,kiki抬头发现,能见度高了很多,竟然能够看到远处的酒店了,她说,现在上去可能能看到。于是,我果断掉头,再向上爬,并且担心大雾随时再起,一路加快了步伐,但因为是向上爬,一路气喘得非常厉害,大概离山顶还有五分钟路程的时候,突然听到一阵欢呼声,这时候,心里就猜到了,一定是“猴子观海”处的大雾散去,众人看到了这一景观。这时,虽然因为爬的急,已经很累了,但是依旧是一鼓作气,咬牙爬上山顶,到达了猴子观海观景台。

    雾依旧有一些,但风也起来了,风吹着雾气到处乱逃。远处的胜景–“猴子观海”终于呈现在了眼前。随着大风的持续作用,猴子观海周围的各式山峰也都明朗了起来。

    大概,在这时候,心里就暗下决心,黄山一定还是要来的,因为此番景色,只能用眼睛、用双脚、用心灵去体会。

    猴子观海@2023年4月29日 清晨

    长恨春归无觅处

    因为气候的原因,山上更冷,春意也更晚。很多城市里的花都已经盛开,甚至开始凋落,但是注意黄山之上,杜鹃花(据说是一种比较独特的杜鹃)却刚刚盛开,很多的小树也还是刚刚冒出新芽。想恰如白居易所言:“长恨春归无觅处,不知转入此中来”。

    黄山山顶的酒店

    这次我们一行5人,老爸年过六旬,小娃刚刚六岁,所以整个行程安排得非常“松散”,首日上线,先入住了玉屏楼酒店,次日走过光明顶,再到狮林大酒店,第三日经过始信峰后从云谷索道下山。

    酒店的价格大家可以在携程等站点查询,会因为假期等原因波动很大。但,无论如何,黄山山顶的酒店都不便宜,一方面酒店数量不多,就那么几家,另一方面山顶所有使用的物品都需要从山下经由索道运至山腰,然后再由挑夫人力挑至山顶,走过一趟的都能体会这种不易,所以,价格贵一些,都是正常。

    另外,如果住在山上,吃饭是另一个比较大的费用,一般酒店的自助餐(似乎只有自助餐)大概在每人120~160元之间。另外,山顶有一些休息站,会供应一些盒饭,价格在50~80元。

    总得来说,没有必要带很多的水和食物,基本都能够买到,虽然略微贵一些。

    再说一说玉屏楼酒店吧。这个酒店所在的位置比较险峻,并且正对着著名的“迎客松”,左边是天都峰,右边是莲花峰,背后也有各式各样的奇石奇松,不远处可以到莲花亭,可以观看日出日落。可以说是非常有特色的酒店。

    上面的照片是在去莲花亭的路上所拍,远处的高峰正是“天都峰”,中间靠左隐约可见的房子就是玉屏楼酒店,如果注意看的话,酒店靠右一点则是黄山著名的“迎客松”。

  • 本文重点介绍了MySQL领域最新的书籍:《MySQL实战》,以及2020左右推出的书籍《MySQL是怎样运行的》。

    《MySQL实战》,作者陈臣

    上个月,MySQL领域又发布了一本新书:《MySQL实战》,作者是陈臣,来自Oracle的工程师,一直活跃在MySQL数据库领域。本文概要的介绍一下,这是一本怎样的书,以及合适哪些人阅读。

    《MySQL实战》这本书更加偏重实践、深入原理相结合的方式介绍MySQL,是非常适合希望能够系统的、更加深入的了解MySQL的开发者或DBA的,例如从事的工作与MySQL数据库密切相关,涉及到MySQL的管理、问题排查、调优选型等。如果做一般性的了解,则可以选择性的阅读其中的章节和内容。

    具体的,如果你从事的工作与需要进行复制配置与管理,那么则可以考虑深入阅读第二章”复制“;如果,你的工作中需要处理Binlog,例如需要进行增量数据解析与获取,则可以精读第三章”深入解析Binlog“。

    相比于官方手册,该书籍在实践方面是更接地气的,这一点上,这本书也是MySQL官方手册的很好补充。

    例如,如果想系统的了解MySQL的备份,本书在第五章系统的介绍各种MySQL的备份方法。涵盖了官方提供的mysqldump,也包括在社区使用非常广泛的mydumper和XtraBackup。如果只是阅读官方手册的话,你可能只会看到关于mysqldump的相关介绍,但在实际的生产使用中,尤其是海量数据备份时,XtraBackup和mydumper都被广泛使用。

    再比如,大表DDL一直是MySQL的一个”硬伤“,在系统运行较长时间后,都会遇到这个令人头疼的问题。本书的第七章就叫”DDL“,单独的介绍了这个online DDL的现状以及常用的解决方案。不仅包含了官方MySQL中的online DDL支持,也涵盖了在社区最为广泛使用的两个工具pt-osc和gh-ost。

    《MySQL是怎样运行的》

    另外,也补充介绍一下2020年的书《MySQL是怎样运行的》。这本书封面上写的作者名字是”小孩子4919“,可见作者更加有个性,这也体现在书籍中。书中,一般会用打比方的方式介绍或者引入数据库的一些概念,然后再较为深入的进行介绍。非常适合新手从零开始学习MySQL,了解他的基本概念,以及对应的原理。在覆盖面上,涵盖了诸如安装配置、字符集、InnoDB、查询优化基础、事务等相关内容,并且都尽可能从非常基础的开始讲起。

    例如,在介绍MySQL启动选项和系统变量的时候,作者使用了手机中的“设置”进行类比;再比如,很少有书籍会介绍“字符集和比较规则”,但这也是一个新手难以理解的地方,本书则使用了独立章节进行介绍,并从计算机底层的二进制存储开始引入结束,可以说是深入浅出。

    当然,作者也做了一些取舍,也就只能放弃非常深入全面的解析每个模块的细枝末节。总得来说,这本书作为打开MySQL大门的引导,是非常合适的。

    是《MySQL实战》,不是《MySQL实战45讲》

    另外,“MySQL实战”在领域还有一个非常有名系列是由丁奇和极客时间推出“MySQL实战45讲”。本书和该系列没有什么直接关系。

    最后

    最后,搜索引擎这么强大,为什么还要读书?相比互联网上零散的信息与知识,书籍则提供完整的、系统的介绍某个领域的知识。而,作为专业领域的从业者,通常都需要了解领域的方方面面,书籍或者手册则是非常好开始。

  • 重要更新

    4月28日,向量数据库平台Pinecone在B轮获得1亿美元融资,估值达到7.5亿美元:参考;而在之前一周,4月22日,开源向量数据库Weaviate也宣布获得5000万美元(约3.5亿元)B轮融资;来自中国的同类产品Milvus也在去年9月获得B+6000万美元的融资。

    更新详情

    AWS
    • Aurora Serverless v1支持PostgreSQL 13,同时支持11到13的原地升级:参考
    • Aurora Serverless v1实例支持转成普通预留实例:参考
    • RDS PostgreSQL支持扩展pgvector,内置了ML模型,可实现向量搜索:参考
    GCP
    • Spanner发布了历史执行计划采样展示功能(Preview): 参考
    • 托管PostgreSQL支持快速迁移功能,可以更快速的将外部数据迁移到GCP:参考
    • 托管SQL Server支持禁用 simultaneous multithreading (SMT) 功能以减少客户所需的授权费用
    • Spanner单表支持的索引个数由32个增长为128个: 参考
    • 保底折扣( Committed use discounts)支持托管Redis和Memcached
    • AlloyDB支持节点状态(CPU使用/负责延迟/uptime)指标数据:参考
    Azure
    • 托管Databricks服务的Serverless SQL功能正式GA:参考

    推荐阅读

  • 不可见索引(Invisible Indexes)MySQL 8.0之后引入的一个重要特性。也可以帮助DBA或者开发者更好的管理和维护数据库的索引。本文将介绍不可见索引的一些常见使用场景和注意事项。

    更加安全的删除没用的索引

    通常,线上运行时间较长的系统,可以通过索引使用统计信息知道哪些索引是从来不被使用的,但依旧会占用磁盘空间,并且会影响系统的写入/更新/删除操作的性能。但是删除索引的操作,有时候也会带来意想不到的系统性能下降,所以,在正式删除之前,可以先将索引修改为不可用,待观察数日后再进行删除,会更加安全。

    性能分析

    有时候在对线上系统进行SQL性能分析时,有时候为了排除某些索引对查询性能影响时,可以暂时的将某些索引暂时标记为不可用,再统计此时的SQL执行时长与性能。然后,再将索引置为可见,再次执行SQL,并统计执行时长与性能。

    通过这样对比,可以非常简单直观、量化的观察到索引对对于具体SQL性能的提升。

    不可见索引依旧会有维护成本

    虽然不可见索引不会被查询优化器使用,但在对数据进行DML操作(如:插入、更新、删除)时仍会被维护。这意味着不可见索引可能会对数据库性能产生一定影响。在使用不可见索引进行性能测试或分析时,请务必权衡这一点。

    不建议长期保留不可见索引

    如果确定某个不可见索引对查询性能没有帮助,建议尽早删除该索引,以节省存储空间和减小维护成本。否则,该索引对系统性能没有起到任何正面作用,反而会占用空间,并影响DML的性能。

    优化器选项可以让不可见索引生效

    在优化器选项(optimizer_switch)中,可以通过打开标记位(use_invisible_indexes),来强制优化器忽略索引的不可见属性,这在增加了SQL性能调试时的灵活性。

    可以通过SELECT/SHOW命令查询优化器选项,也可用通过SET命令变更该选项:

    SET [GLOBAL|SESSION] optimizer_switch='command[,command]...';
    
    SET SESSION optimizer_switch = 'use_invisible_indexes=ON';