在這些年的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è)主要原因是：驅(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è)贛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帶來(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è)試和案例分析支撐。
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn)，該文觀點(diǎn)僅代表作者本人。本站僅提供信息存儲(chǔ)空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請(qǐng)發(fā)送郵件至2705686032@qq.com 舉報(bào)，一經(jīng)查實(shí)，本站將立刻刪除。原文轉(zhuǎn)載： 原文出處：
