MySQL 5.7和MySQL 8.0的4个细节差异
这是学习笔记的第 2302篇文章
在这些年的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%兼容,要拍胸脯保证的事情,得有深入的测试和案例分析支撑。
各大平台都可以找到我
微信公众号:杨建荣的学习笔记
Github:@jeanron100
CSDN:@jeanron100
知乎:@jeanron100
头条号:@杨建荣的学习笔记
网易号:@杨建荣的数据库笔记
大鱼号:@杨建荣的数据库笔记
腾讯云+社区:@杨建荣的学习笔记
近期热文:
转载热文:
QQ群号:763628645
QQ群二维码如下, 添加请注明:姓名+地区+职位,否则不予通过
点在看,让更多人看到
本文地址:https://blog.csdn.net/yangjianrong1985/article/details/112001081
推荐阅读
-
php7和mysql5.7的升级历程
-
怎么比较mysql里不同的两张表的差异;还有mysql和postgres之间同表的差异比较?
-
Windows 64 位 mysql 5.7以上版本包解压中没有data目录和my-default.ini及服务无法启动的快速解决办法(问题小结)
-
Linux系统下 MySQL 安装 指南(5.7和8.0 版本)
-
MySQL5.7中 performance和sys schema中的监控参数解释(推荐)
-
MySQL 5.7及8.0版本数据库的root密码遗忘的解决方法
-
Windows 64 位 mysql 5.7以上版本包解压中没有data目录和my-default.ini及服务无法启动的快速解决办法(问题小结)
-
Linux系统下 MySQL 安装 指南(5.7和8.0 版本)
-
Win10下免安装版MySQL5.7的安装和配置
-
MySQL5.7版本的下载和安装