[[361267]]

在這些年的MySQL升級需求中，讓我大跌眼鏡的一個現(xiàn)象是：驅動業(yè)務從MySQL 5.5升級到MySQL 5.7的很大一個因素是因為JSON這個特性。

而讓業(yè)務有所顧慮從MySQL 5.7升級到MySQL 8.0的一個主要原因是因為驅動版本升級，所以對于MySQL 5.7升級到MySQL 8.0來說，總體的升級動力明顯要低一些，但是規(guī)劃的一個優(yōu)點就是可以把一些工作前置，或者讓它的推行更加順暢，比如我們對于新業(yè)務的推行，都是默認按照MySQL 8.0的方案來做。

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

細節(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è)務側是后知后覺，原本已經(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的表結構配置

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; 

如果查看在線業(yè)務的實際數(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)來間接轉義了，但是實際上還是不對味。

帶來的問題是在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

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

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

本文轉載自微信公眾號「楊建榮的學習筆記」，可以通過以下二維碼關注。轉載本文請聯(lián)系楊建榮的學習筆記公眾號。