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