MySQL 5.7和MySQL 8.0的4個細節(jié)差異
在這些年的MySQL升級需求中，讓我大跌眼鏡的一個現(xiàn)象是：驅(qū)動業(yè)務(wù)從MySQL 5.5升級到MySQL 5.7的很大一個因素是因為JSON這個特性。
而讓業(yè)務(wù)有所顧慮從MySQL 5.7升級到MySQL 8.0的一個主要原因是因為驅(qū)動版本升級，所以對于MySQL 5.7升級到MySQL 8.0來說，總體的升級動力明顯要低一些，但是規(guī)劃的一個優(yōu)點就是可以把一些工作前置，或者讓它的推行更加順暢，比如我們對于新業(yè)務(wù)的推行，都是默認按照MySQL 8.0的方案來做。
如果要說MySQL 5.7升級到MySQL 8.0的一些差異，從我的角度來說，其實變化是很大的，但是細數(shù)盤點，很多特性似乎是對于業(yè)務(wù)的一種友好或者透明支持。
細節(jié)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帶來的很多特性是在體驗和性能改造方面，原來不建議使用的模式竟然可以支持了，而很多業(yè)務(wù)側(cè)是后知后覺，原本已經(jīng)培養(yǎng)的習慣，讓我們有些凌亂。
細節(jié)2：
在MySQL 5.7中字段名為rank是可以的，但是在8.0中因為有了窗口函數(shù)，字段名為rank就報錯，順著這個思路，其實我們一窺窗口函數(shù)。
其實就會發(fā)現(xiàn)不光是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
細節(jié)3：
這里順便吐槽下airflow的表結(jié)構(gòu)配置
airflow的一個表結(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中其實會被默認轉(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ù)據(jù)如下：
- mysql> select * from kube_resource_version;
- +------------+------------------+
- | one_row_id | resource_version |
- +------------+------------------+
- | 1 | |
- +------------+------------------+
- 1 row in set (0.01 sec)
看起來這個boolean類型真是有些雞肋，在數(shù)據(jù)庫中已經(jīng)默認使用tinyint(1)來間接轉(zhuǎn)義了，但是實際上還是不對味。
帶來的問題是在MySQL 5.7中可以成功創(chuàng)建，但是在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'.
而經(jīng)過分析，其實8.0的報錯提示更加合理，至少我覺得8.0對于數(shù)據(jù)層面的要求確實變高了。
細節(jié)4：
在MySQL里面如果對一張大表做delete,真是一件讓人尷尬的事情，在MySQL 5.7里面有點后知后覺，在show processlist的輸出中。State和Info列分別顯示：
Executing event 和delete from xxxxx
同時Seconds_Behind_Master顯示為0，實際上數(shù)據(jù)已經(jīng)產(chǎn)生大量延遲了。
而相反在MySQL 8.0里面，State和Info列分別顯示：
Applying batch of row changes (delete)和delete from xxxxx
可以明確的提示出批量操作，當然這延遲確實不體面，真是非常大。
簡單小結(jié)：MySQL 8.0里面的很多細節(jié)還是很接地氣，也不能潛意識的認為是100%兼容，要拍胸脯保證的事情，得有深入的測試和案例分析支撐。
本文轉(zhuǎn)載自微信公眾號「楊建榮的學習筆記」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系楊建榮的學習筆記公眾號。
