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

139次閱讀

共計(jì) 2680 個(gè)字符，預(yù)計(jì)需要花費(fèi) 7 分鐘才能閱讀完成。

本篇內(nèi)容主要講解“MySQL 5.7 和 MySQL 8.0 的細(xì)節(jié)差異有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓丸趣 TV 小編來(lái)帶大家學(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)?JSON 這個(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 來(lái)說(shuō)，總體的升級(jí)動(dòng)力明顯要低一些，但是規(guī)劃的一個(gè)優(yōu)點(diǎn)就是可以把一些工作前置，或者讓它的推行更加順暢，比如我們對(duì)于新業(yè)務(wù)的推行，都是默認(rèn)按照 MySQL 8.0 的方案來(lái)做。

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

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

比如我們?cè)?MySQL 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 帶來(lái)的很多特性是在體驗(yàn)和性能改造方面，原來(lái)不建議使用的模式竟然可以支持了，而很多業(yè)務(wù)側(cè)是后知后覺(jué)，原本已經(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 也不可以了，隨之帶來(lái)的就是 SQL 語(yǔ)法錯(cuò)誤，可能會(huì)讓人開(kāi)始有點(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)

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

帶來(lái)的問(wèn)題是在 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)過(guò)分析，其實(shí) 8.0 的報(bào)錯(cuò)提示更加合理，至少我覺(jué)得 8.0 對(duì)于數(shù)據(jù)層面的要求確實(shí)變高了。

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

在 MySQL 里面如果對(duì)一張大表做 delete, 真是一件讓人尷尬的事情，在 MySQL 5.7 里面有點(diǎn)后知后覺(jué)，在 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é)差異有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是丸趣 TV 網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

正文完