MySQL 5.7和MySQL 8.0的細(xì)節(jié)差異有哪些

本篇內(nèi)容主要講解“MySQL 5.7和MySQL 8.0的細(xì)節(jié)差異有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“MySQL 5.7和MySQL 8.0的細(xì)節(jié)差異有哪些”吧!

在這些年的MySQL升級(jí)需求中，讓我大跌眼鏡的一個(gè)現(xiàn)象是：驅(qū)動(dòng)業(yè)務(wù)從MySQL 5.5升級(jí)到MySQL  5.7的很大一個(gè)因素是因?yàn)镴SON這個(gè)特性。

而讓業(yè)務(wù)有所顧慮從MySQL 5.7升級(jí)到MySQL 8.0的一個(gè)主要原因是因?yàn)轵?qū)動(dòng)版本升級(jí)，所以對(duì)于MySQL 5.7升級(jí)到MySQL  8.0來說，總體的升級(jí)動(dòng)力明顯要低一些，但是規(guī)劃的一個(gè)優(yōu)點(diǎn)就是可以把一些工作前置，或者讓它的推行更加順暢，比如我們對(duì)于新業(yè)務(wù)的推行，都是默認(rèn)按照MySQL  8.0的方案來做。

如果要說MySQL 5.7升級(jí)到MySQL  8.0的一些差異，從我的角度來說，其實(shí)變化是很大的，但是細(xì)數(shù)盤點(diǎn)，很多特性似乎是對(duì)于業(yè)務(wù)的一種友好或者透明支持。

細(xì)節(jié)1：

比如我們?cè)贛ySQL 5.7版本中全面推行GTID，所以之前的create table xxx as select * from  xx的使用模式就不奏效了，進(jìn)而我們建議使用：

create table xxx like xxxxx;  insert into xxx select * from xxxxx;

這種使用模式，而MySQL8.0帶來的很多特性是在體驗(yàn)和性能改造方面，原來不建議使用的模式竟然可以支持了，而很多業(yè)務(wù)側(cè)是后知后覺，原本已經(jīng)培養(yǎng)的習(xí)慣，讓我們有些凌亂。

細(xì)節(jié)2：

在MySQL 5.7中字段名為rank是可以的，但是在8.0中因?yàn)橛辛舜翱诤瘮?shù)，字段名為rank就報(bào)錯(cuò)，順著這個(gè)思路，其實(shí)我們一窺窗口函數(shù)。

其實(shí)就會(huì)發(fā)現(xiàn)不光是rank,字段名是first_value也不可以了，隨之帶來的就是SQL語(yǔ)法錯(cuò)誤，可能會(huì)讓人開始有點(diǎn)抓不著頭腦。

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

細(xì)節(jié)3：

這里順便吐槽下airflow的表結(jié)構(gòu)配置

airflow的一個(gè)表結(jié)構(gòu)在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中其實(shí)會(huì)被默認(rèn)轉(zhuǎn)換為如下的表結(jié)構(gòu)： 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;

如果查看在線業(yè)務(wù)的實(shí)際數(shù)據(jù)如下：

mysql> select * from kube_resource_version; +------------+------------------+ | one_row_id | resource_version | +------------+------------------+ |          1 |                  | +------------+------------------+ 1 row in set (0.01 sec)

看起來這個(gè)boolean類型真是有些雞肋，在數(shù)據(jù)庫(kù)中已經(jīng)默認(rèn)使用tinyint(1)來間接轉(zhuǎn)義了，但是實(shí)際上還是不對(duì)味。

帶來的問題是在MySQL 5.7中可以成功創(chuàng)建，但是在8.0會(huì)報(bào)錯(cuò)：

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'.

而經(jīng)過分析，其實(shí)8.0的報(bào)錯(cuò)提示更加合理，至少我覺得8.0對(duì)于數(shù)據(jù)層面的要求確實(shí)變高了。

細(xì)節(jié)4：

在MySQL里面如果對(duì)一張大表做delete,真是一件讓人尷尬的事情，在MySQL 5.7里面有點(diǎn)后知后覺，在show  processlist的輸出中。State和Info列分別顯示：

Executing event 和delete from xxxxx

同時(shí)Seconds_Behind_Master顯示為0，實(shí)際上數(shù)據(jù)已經(jīng)產(chǎn)生大量延遲了。

而相反在MySQL 8.0里面，State和Info列分別顯示：

Applying batch of row changes (delete)和delete from xxxxx

可以明確的提示出批量操作，當(dāng)然這延遲確實(shí)不體面，真是非常大。

簡(jiǎn)單小結(jié)：MySQL 8.0里面的很多細(xì)節(jié)還是很接地氣，也不能潛意識(shí)的認(rèn)為是100%兼容，要拍胸脯保證的事情，得有深入的測(cè)試和案例分析支撐。

到此，相信大家對(duì)“MySQL 5.7和MySQL 8.0的細(xì)節(jié)差異有哪些”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！