MySQL 5.7和MySQL 8.0的細節差異有哪些

本篇內容主要講解“MySQL 5.7和MySQL 8.0的細節差異有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MySQL 5.7和MySQL 8.0的細節差異有哪些”吧!

在這些年的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%兼容，要拍胸脯保證的事情，得有深入的測試和案例分析支撐。

到此，相信大家對“MySQL 5.7和MySQL 8.0的細節差異有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！