共计 2680 个字符,预计需要花费 7 分钟才能阅读完成。
本篇内容主要讲解“MySQL 5.7 和 MySQL 8.0 的细节差异有哪些”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让丸趣 TV 小编来带大家学习“MySQL 5.7 和 MySQL 8.0 的细节差异有哪些”吧!
在这些年的 MySQL 升级需求中,让我大跌眼镜的一个现象是:驱动业务从 MySQL 5.5 升级到 MySQL 5.7 的很大一个因素是因为 JSON 这个特性。
而让业务有所顾虑从 MySQL 5.7 升级到 MySQL 8.0 的一个主要原因是因为驱动版本升级,所以对于 MySQL 5.7 升级到 MySQL 8.0 来说,总体的升级动力明显要低一些,但是规划的一个优点就是可以把一些工作前置,或者让它的推行更加顺畅,比如我们对于新业务的推行,都是默认按照 MySQL 8.0 的方案来做。
如果要说 MySQL 5.7 升级到 MySQL 8.0 的一些差异,从我的角度来说,其实变化是很大的,但是细数盘点,很多特性似乎是对于业务的一种友好或者透明支持。
细节 1:
比如我们在 MySQL 5.7 版本中全面推行 GTID,所以之前的 create table xxx as select * from xx 的使用模式就不奏效了,进而我们建议使用:
create table xxx like xxxxx; insert into xxx select * from xxxxx;
这种使用模式,而 MySQL8.0 带来的很多特性是在体验和性能改造方面,原来不建议使用的模式竟然可以支持了,而很多业务侧是后知后觉,原本已经培养的习惯,让我们有些凌乱。
细节 2:
在 MySQL 5.7 中字段名为 rank 是可以的,但是在 8.0 中因为有了窗口函数,字段名为 rank 就报错,顺着这个思路,其实我们一窥窗口函数。
其实就会发现不光是 rank, 字段名是 first_value 也不可以了,随之带来的就是 SQL 语法错误,可能会让人开始有点抓不着头脑。
create table test3(id int primary key,first_value varchar(30));
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near first_value varchar(30)) at line 1
细节 3:
这里顺便吐槽下 airflow 的表结构配置
airflow 的一个表结构在 MySQL 5.7 中如下:
CREATE TABLE kube_resource_version (one_row_id BOOL NOT NULL DEFAULT true, resource_version VARCHAR(255), PRIMARY KEY (one_row_id), CONSTRAINT kube_resource_version_one_row_id CHECK (one_row_id), CHECK (one_row_id IN (0, 1))); Query OK, 0 rows affected (0.06 sec) 在 MySQL 中其实会被默认转换为如下的表结构: CREATE TABLE `kube_resource_version` ( `one_row_id` tinyint(1) NOT NULL DEFAULT 1 , `resource_version` varchar(255) DEFAULT NULL, PRIMARY KEY (`one_row_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
如果查看在线业务的实际数据如下:
mysql select * from kube_resource_version; +------------+------------------+ | one_row_id | resource_version | +------------+------------------+ | 1 | | +------------+------------------+ 1 row in set (0.01 sec)
看起来这个 boolean 类型真是有些鸡肋,在数据库中已经默认使用 tinyint(1) 来间接转义了,但是实际上还是不对味。
带来的问题是在 MySQL 5.7 中可以成功创建,但是在 8.0 会报错:
CREATE TABLE kube_resource_version (one_row_id BOOL NOT NULL DEFAULT true, resource_version VARCHAR(255), PRIMARY KEY (one_row_id), CONSTRAINT kube_resource_version_one_row_id CHECK (one_row_id), CHECK (one_row_id IN (0, 1))); ERROR 3812 (HY000): An expression of non-boolean type specified to a check constraint kube_resource_version_one_row_id .
而经过分析,其实 8.0 的报错提示更加合理,至少我觉得 8.0 对于数据层面的要求确实变高了。
细节 4:
在 MySQL 里面如果对一张大表做 delete, 真是一件让人尴尬的事情,在 MySQL 5.7 里面有点后知后觉,在 show processlist 的输出中。State 和 Info 列分别显示:
Executing event 和 delete from xxxxx
同时 Seconds_Behind_Master 显示为 0,实际上数据已经产生大量延迟了。
而相反在 MySQL 8.0 里面,State 和 Info 列分别显示:
Applying batch of row changes (delete) 和 delete from xxxxx
可以明确的提示出批量操作,当然这延迟确实不体面,真是非常大。
简单小结:MySQL 8.0 里面的很多细节还是很接地气,也不能潜意识的认为是 100% 兼容,要拍胸脯保证的事情,得有深入的测试和案例分析支撑。
到此,相信大家对“MySQL 5.7 和 MySQL 8.0 的细节差异有哪些”有了更深的了解,不妨来实际操作一番吧!这里是丸趣 TV 网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!