MySQL 5.7和MySQL 8.0的4个细节差异

 

在这些年的个细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%兼容，要拍胸脯保证的事情，得有深入的测试和案例分析支撑。

本文转载自微信公众号「杨建荣的学习笔记」，可以通过以下二维码关注。转载本文请联系杨建荣的学习笔记公众号。

很赞哦!（772）