Mysql8.0.11簡介，新特性

時間 2019-11-14

原文原文鏈接

MySQL 8.0 正式版 8.0.11 已發佈，官方表示 MySQL 8 要比 MySQL 5.7 快 2 倍，還帶來了大量的改進和更快的性能！html

注意：從 MySQL 5.7 升級到 MySQL 8.0 僅支持經過使用 in-place 方式進行升級，而且不支持從 MySQL 8.0 降級到 MySQL 5.7（或從某個 MySQL 8.0 版本降級到任意一個更早的 MySQL 8.0 版本）。惟一受支持的替代方案是在升級以前對數據進行備份。mysql

MySQL 8.0是全球最受歡迎的開源數據庫的一個很是使人興奮的新版本，全面改進。一些關鍵的加強包括：

SQL窗口函數，公用表表達式，NOWAIT和SKIP LOCKED，降序索引，分組，正則表達式，字符集，成本模型和直方圖。

JSON擴展語法，新功能，改進排序和部分更新。使用JSON表函數，您可使用JSON數據的SQL機制。

GIS地理支持。空間參考系統（SRS），以及SRS感知空間數據類型，空間索引和空間功能。

可靠性 DDL語句已變得原子性和崩潰安全，元數據存儲在單個事務數據字典中。由InnoDB提供支持！

可觀察性性能架構，信息架構，配置變量和錯誤記錄的顯着加強。

可管理性遠程管理，撤消表空間管理和新的即時DDL。

安全 OpenSSL改進，新的默認身份驗證，SQL角色，分解超級特權，密碼強度等等。

性能 InnoDB在讀/寫工做負載，IO綁定工做負載和高爭用「熱點」工做負載方面明顯更好。增長了資源組功能，經過將用戶線程映射到CPU，爲用戶提供一個選項，以針對特定硬件上的特定工做負載進行優化

開發者功能

MySQL開發人員須要新功能，而MySQL 8.0在諸如SQL，JSON，正則表達式和GIS等領域提供了許多新的和更多需求的功能。開發人員也但願可以存儲Emojis，所以UTF8MB4如今是8.0中的默認字符集。最後，數據類型獲得了改進，在BINARY數據類型上進行了按位操做，而且改進了IPv6和UUID功能。

下面簡要介紹 MySQL 8 中值得關注的新特性和改進。正則表達式

1. 性能：MySQL 8.0 的速度要比 MySQL 5.7 快 2 倍。MySQL 8.0 在如下方面帶來了更好的性能：讀/寫工做負載、IO 密集型工做負載、以及高競爭（"hot spot"熱點競爭問題）工做負載。算法

2. NoSQL：MySQL 從 5.7 版本開始提供 NoSQL 存儲功能，目前在 8.0 版本中這部分功能也獲得了更大的改進。該項功能消除了對獨立的 NoSQL 文檔數據庫的需求，而 MySQL 文檔存儲也爲 schema-less 模式的 JSON 文檔提供了多文檔事務支持和完整的 ACID 合規性。sql

3. 窗口函數(Window Functions)：從 MySQL 8.0 開始，新增了一個叫窗口函數的概念，它能夠用來實現若干新的查詢方式。窗口函數與 SUM()、COUNT() 這種集合函數相似，但它不會將多行查詢結果合併爲一行，而是將結果放回多行當中。即窗口函數不須要 GROUP BY。數據庫

4. 隱藏索引：在 MySQL 8.0 中，索引能夠被「隱藏」和「顯示」。當對索引進行隱藏時，它不會被查詢優化器所使用。咱們可使用這個特性用於性能調試，例如咱們先隱藏一個索引，而後觀察其對數據庫的影響。若是數據庫性能有所降低，說明這個索引是有用的，而後將其「恢復顯示」便可；若是數據庫性能看不出變化，說明這個索引是多餘的，能夠考慮刪掉。數組

5. 降序索引：MySQL 8.0 爲索引提供按降序方式進行排序的支持，在這種索引中的值也會按降序的方式進行排序。緩存

6. 通用表表達式(Common Table Expressions CTE)：在複雜的查詢中使用嵌入式表時，使用 CTE 使得查詢語句更清晰。安全

7. UTF-8 編碼：從 MySQL 8 開始，使用 utf8mb4 做爲 MySQL 的默認字符集。服務器

8. JSON：MySQL 8 大幅改進了對 JSON 的支持，添加了基於路徑查詢參數從 JSON 字段中抽取數據的 JSON_EXTRACT() 函數，以及用於將數據分別組合到 JSON 數組和對象中的 JSON_ARRAYAGG() 和 JSON_OBJECTAGG() 聚合函數。

9. 可靠性：InnoDB 如今支持表 DDL 的原子性，也就是 InnoDB 表上的 DDL 也能夠實現事務完整性，要麼失敗回滾，要麼成功提交，不至於出現 DDL 時部分紅功的問題，此外還支持 crash-safe 特性，元數據存儲在單個事務數據字典中。

10. 高可用性(High Availability)：InnoDB 集羣爲您的數據庫提供集成的原生 HA 解決方案。

11. 安全性：對 OpenSSL 的改進、新的默認身份驗證、SQL 角色、密碼強度、受權。

詳細說明：

窗口函數

MySQL 8.0提供了SQL窗口功能。與分組集合函數相似，窗口函數對一組行進行一些計算，例如COUNT或SUM。可是，若是分組聚合將這組行集合到一行中，則窗口函數將爲結果集中的每一行執行聚合。

窗口函數有兩種形式：用做窗口函數和專用窗口函數的SQL聚合函數。這是MySQL中支持窗口化的集合函數集合：COUNT，SUM，AVG，MIN，MAX，BIT_OR，BIT_AND，BIT_XOR，STDDEV_POP（及其同義詞STD，STDDEV），STDDEV_SAMP，VAR_POP（及其同義詞VARIANCE）和VAR_SAMP。這組專門的窗口函數是：RANK，DENSE_RANK，PERCENT_RANK，CUME_DIST，NTILE，ROW_NUMBER，FIRST_VALUE，LAST_VALUE，NTH_VALUE，LEAD和LAG

對窗口函數（又名分析函數）的支持是一種頻繁的用戶請求。窗口函數一直是標準SQL（SQL 2003）的一部分。在這裏能夠看到Dag Wanvik的博客文章以及Guilhem Bichot 在這裏的博客文章。

公用表表達式

MySQL 8.0提供[遞歸]公用表表達式（CTE）。非遞歸CTE能夠解釋爲「改進的派生表」，由於它容許派生表被屢次引用。遞歸CTE是一組迭代構建的行：從最初的一組行開始，一個進程派生新的行，而後將這些新的行從新輸入到進程中，產生更多的行，等等，直到該過程再也不生成行。CTE是一個一般須要的SQL功能，請參閱功能請求16244和32174。見吉揚Bichot博客文章在這裏，這裏，這裏和這裏。

NOWAIT和SKIP LOCKED

MySQL的8.0提供了NOWAIT與SKIP LOCKED該SQL鎖定子句中的替代品。一般，當某行因爲某個UPDATE或某一行而被鎖定時SELECT ... FOR UPDATE，任何其餘事務都必須等待才能訪問該鎖定的行。在某些使用狀況下，若是行被鎖定或忽略鎖定行，則須要當即返回。使用鎖定子句NOWAIT永遠不會等待獲取行鎖。相反，查詢將失敗並顯示錯誤。使用鎖定子句SKIP LOCKED永遠不會等待獲取列出的表上的行鎖。相反，鎖定的行將被跳過而且不會被讀取。NOWAIT和SKIP LOCKED是常常請求的SQL功能。請參閱功能請求49763。咱們也想對Kyle Oppenheim 說聲謝謝爲他的代碼貢獻！請參閱Martin Hansson 在這裏發表的博文。

GROUPING

MySQL 8.0提供GROUPING()，SQL_FEATURE T433。該GROUPING()功能區分超常規行與常規分組行。GROUP BY諸如ROLLUP產生超集合行的擴展，其中全部值的集合由空值表示。使用該GROUPING()函數，您能夠區分表示超常聚合行中全部值的集合的null與NULL常規行中的值。GROUPING是一個頻繁請求的SQL功能。請參閱功能請求3156和46053。感謝Zoe Dong和Shane Adams在功能請求46053中的代碼貢獻！見Chaithra Gopalareddy博客文章在這裏。

優化器提示

在5.7中，咱們爲優化器提示引入了一種新的提示語法。使用新的語法，能夠SELECT | INSERT | REPLACE | UPDATE | DELETE在SQL語句中的關鍵字以後直接指定提示，並將其用/*+ */風格註釋括起來。（見這裏的Sergey Glukhov博客文章5.7 ）。在MySQL 8.0中，咱們經過充分利用這種新風格來完成圖片：

MySQL 8.0增長了INDEX_MERGE和的提示NO_INDEX_MERGE。這容許用戶在不更改優化器開關的狀況下控制單個查詢的索引合併行爲。

MySQL的8.0增長了用於提示JOIN_FIXED_ORDER，JOIN_ORDER，JOIN_PREFIX，和JOIN_SUFFIX。這容許用戶控制聯合執行的表順序。

MySQL 8.0添加了一個叫作提示SET_VAR。該SET_VAR提示將針對只剩下一語句給定的系統變量設置的值。所以，語句結束後，該值將重置爲先前的值。在這裏能夠看到Sergey Glukhov的博客文章。

咱們更傾向於將新風格的優化器提示視爲優於舊式提示和optimizer_switch值設置。經過不與SQL混合，新的提示能夠在查詢字符串中的許多地方注入。他們在提示（vs指令）方面也有更清晰的語義。

JSON

MySQL 8.0增長了新的JSON函數，並提升了排序和分組JSON值的性能。

JSON路徑表達式中的範圍的擴展語法

MySQL 8.0擴展了JSON路徑表達式中範圍的語法。例如SELECT JSON_EXTRACT('[1, 2, 3, 4, 5]', '$[1 to 3]');結果[2, 3, 4]。引入的新語法是SQL標準語法的一個子集，在SQL：2016，9.39 SQL / JSON路徑語言中描述：語法和語義。參見Roland Bouman所報告的Bug＃79052。

JSON表函數

MySQL 8.0增長了JSON表函數，可使用JSON數據的SQL機制。JSON_TABLE()建立JSON數據的關係視圖。它將JSON數據評估的結果映射到關係行和列。用戶可使用SQL查詢函數返回的結果爲常規關係表，例如join，project和aggregate。

JSON聚合函數

MySQL 8.0添加了聚合函數JSON_ARRAYAGG()來生成JSON數組並JSON_OBJECTAGG()生成JSON對象。這使得將多行中的JSON文檔組合成JSON數組或JSON對象成爲可能。見克特林Besleaga博客文章在這裏。

JSON合併函數

該JSON_MERGE_PATCH()函數實現RFC7396指定的JavaScript（和其餘腳本語言）的語義，即它經過第二個文檔的優先級去除重複項。例如，。JSON_MERGE('{"a":1,"b":2 }','{"a":3,"c":4 }'); # returns {"a":3,"b":2,"c":4}

例如，該JSON_MERGE_PRESERVE()函數具備在MySQL 5.7中實現的JSON_MERGE（）的語義，該語法保留全部值 JSON_MERGE('{"a": 1,"b":2}','{"a":3,"c":4}'); # returns {"a":[1,3],"b":2,"c":4}.

現有的JSON_MERGE()函數在MySQL 8.0中不推薦使用，以消除合併操做的歧義。請參閱Bug＃81283中的提案以及Morgan Tocker 在此處的博文。

JSON漂亮功能

MySQL 8.0 JSON_PRETTY()在MySQL中添加了一個函數。該函數接受JSON本機數據類型或JSON的字符串表示形式，並以新的行和縮進方式以人類可讀的方式返回JSON格式的字符串。

JSON大小函數

MySQL 8.0爲給定的JSON對象添加了與空間使用相關的JSON函數。該JSON_STORAGE_SIZE()回報的JSON數據類型字節的實際大小。在JSON_STORAGE_FREE()返回以字節爲單位，包括分段和填充保存就地更新一個JSON二進制類型的自由空間。

JSON改進排序

MySQL 8.0經過使用可變長度的排序鍵爲排序/分組JSON提供了更好的性能。初步的基準測試顯示，根據使用狀況，分類的改進度提升了1.2至18倍。

JSON部分更新

MySQL的8.0增長了對部分更新支持JSON_REMOVE()，JSON_SET()以及JSON_REPLACE()功能。若是隻更新JSON文檔的某些部分，咱們但願向處理程序提供有關更改內容的信息，以便存儲引擎和複製無需編寫完整文檔。在複製環境中，沒法保證JSON文檔的佈局在從屬設備和主設備上徹底相同，所以物理差別沒法用於減小基於行復制的網絡I / O。所以，MySQL 8.0提供了邏輯差別，即基於行的複製能夠經過線路發送並在從屬設備上從新應用。見克努特安德斯·哈特蘭的博客文章在這裏。

GIS

MySQL 8.0提供地理支持。這包括對空間參考系統（SRS）的元數據支持，以及SRS感知空間數據類型，空間索引和空間函數。簡而言之，MySQL 8.0能夠理解地球表面的緯度和經度座標，例如，能夠在大約5000個支持的空間參考系統中的任何一箇中正確計算地球表面上兩點之間的距離。

空間參考系統（SRS）

的ST_SPATIAL_REFERENCE_SYSTEMS信息模式視圖提供有關空間數據可用的空間參考系統的信息。該視圖基於SQL / MM（ISO / IEC 13249-3）標準。每一個空間參考系統都由一個SRID號碼標識。MySQL 8.0附帶來自EPSG大地參數數據集的大約5000個SRID ，涵蓋地理參考橢球和2d投影（即全部2D空間參考系統）。

SRID感知空間數據類型

空間數據類型能夠用空間參考系統定義進行歸屬，例如SRID 4326，以下所示：CREATE TABLE t1 (g GEOMETRY SRID 4326);SRID在這裏是GEOMETRY數據類型的SQL類型修飾符。插入具備SRID屬性的列中的值必須位於該SRID中。嘗試使用其餘SRID插入值會致使引起異常狀況。未修改的類型（即沒有SRID規範的類型）將繼續接受全部SRID，如前所述。

MySQL 8.0添加了INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNSSQL / MM第3部分中指定的視圖。19.2。這種觀點將列出全部幾何列在MySQL實例，併爲每列將列出標準SRS_NAME，SRS_ID和GEOMETRY_TYPE_NAME。

SRID感知空間索引

空間索引能夠在空間數據類型上建立。空間索引中的列必須聲明爲NOT NULL。例如像這樣：CREATE TABLE t1 (g GEOMETRY SRID 4326 NOT NULL, SPATIAL INDEX(g));

具備空間索引的列應該具備SRID類型修飾符，以容許優化器使用索引。若是在沒有SRID類型修飾符的列上建立空間索引，則會發出警告。

SRID感知空間功能

MySQL的8.0延伸的空間的功能，例如 ST_Distance()和ST_Length()來檢測其參數是在一個地理（橢圓形）和SRS來計算對橢球的距離。到目前爲止，ST_Distance和空間關係，例如ST_Within，ST_Intersects，ST_Contains，ST_Crosses，等支持地理計算。每一個ST函數的行爲如SQL / MM Part 3 Spatial中所定義。

字符集

MySQL 8.0使UTF8MB4成爲默認字符集。SQL性能 - 好比對UTF8MB4字符串進行排序 - 與5.7相比，8.0版本的性能提升了20倍。UTF8MB4是網絡中主要的字符編碼，這一舉措將使絕大多數MySQL用戶的生活更輕鬆。

默認字符集已從更改latin1爲utf8mb4而且默認排序規則從更改latin1_swedish_ci爲utf8mb4_800_ci_ai。

默認值的更改適用於libmysql和服務器命令工具以及服務器自己。

這些更改也反映在MTR測試中，使用新的默認字符集運行。

整理重量和案例映射基於Unicode 9.0.0，由Unicode委員會於2016年6月21日發佈。

已針對latin1（MySQL遺留版）使用了21種語言特定的不區分大小寫排序規則 utf8mb4，例如捷克語排序規則變爲utf8mb4_cs_800_ai_ci。請參閱WL＃9108中的完整列表。在這裏能夠看到Xing Zhang的博客文章。

增長了對區分大小寫和區分變音的支持。MySQL 8.0支持由DUCET（默認Unicode排序規則表）定義的全部3級歸類權重。在這裏能夠看到Xing Zhang的博客文章。

使用三個等級的重量排序字符的日語utf8mb4_ja_0900_as_cs整理utf8mb4。這給了日文正確的排序順序。在這裏能夠看到Xing Zhang的博客文章。

日語有額外的假名敏感功能，utf8mb4_ja_0900_as_cs_ks其中'ks'表明'假名敏感'。在這裏能夠看到Xing Zhang的博客文章。

將全部新的排序規則從Unicode 9.0.0向前更改成NO PAD替代PAD STRING，即將字符串末尾的空格像其餘任何字符同樣處理。這樣作是爲了提升一致性和性能。較舊的排序規則留在原地。

看到的Bernt馬裏烏斯·約翰森也是博客文章在這裏，這裏和這裏。

數據類型

二進制數據類型的按位操做

MySQL 8.0擴展了按位操做（'按位AND'等）以便使用[VAR]BINARY/[TINY|MEDIUM|LONG]BLOB。8.0以前的位操做僅支持整數。若是在二進制文件上使用按位BIGINT操做，則在操做以前將參數隱式轉換爲（64位），所以可能會丟失位。從8.0開始，逐位操做適用於全部數據類型BINARY和BLOB數據類型，能夠輸出參數以免丟失位。

IPV6操縱

MySQL 8.0經過支持BINARY數據類型的按位操做來提升IPv6操做的可用性。在MySQL 5.6咱們介紹了INET6_ATON()和INET6_NTOA()其將文本形式等之間的IPv6地址的功能'fe80::226:b9ff:fe77:eb17'和VARBINARY(16)。可是，到目前爲止，咱們沒法將這些IPv6功能與按位操做相結合，由於這些操做會錯誤地將輸出轉換爲BIGINT。例如，若是咱們有一個IPv6地址而且想要針對網絡掩碼進行測試，咱們如今可使用，由於它能夠正確返回數據類型（128位）。見克特林Besleaga博客文章在這裏。INET6_ATON(address)

& INET6_ATON(network)INET6_ATON()VARBINARY(16)

UUID操做

MySQL的8.0經過實現三個新的SQL函數提升UUID操做的易用性：UUID_TO_BIN()，BIN_TO_UUID()，和IS_UUID()。第一個從UUID格式化文本轉換VARBINARY(16)爲第二個VARBINARY(16)到UUID格式化文本，最後一個檢查UUID格式文本的有效性。存儲爲a的UUID VARBINARY(16)可使用功能索引進行索引。功能UUID_TO_BIN()和UUID_TO_BIN()也能夠洗牌與時間相關的位，在開始移動它們使得指數友好，避免在B樹中的隨機插入，這樣下降了插入時間。這種功能的缺少被認爲是使用UUID的缺點之一。見克特林Besleaga博客文章在這裏。

成本模型

查詢優化器將數據緩衝考慮在內

MySQL 8.0根據有關數據是駐留在內存仍是磁盤上的知識來選擇查詢計劃。這是自動發生的，從最終用戶能夠看出，沒有涉及配置。歷史上，MySQL成本模型假定數據駐留在旋轉磁盤上。與在內存和磁盤上查找數據相關的成本常數如今不一樣，所以，根據對數據位置的瞭解，優化程序將爲這兩種狀況選擇更優化的訪問方法。在這裏查看ØysteinGrøvlen的博客文章。

優化器直方圖

MySQL 8.0實現了直方圖統計。經過使用直方圖，用戶能夠建立表格中列的數據分佈統計信息，一般針對非索引列進行，而後查詢優化器將使用這些統計信息來查找最佳查詢計劃。直方圖統計的主要用途是計算形式爲「COLUMN CONSTANT」的謂詞的選擇性（過濾效果）。

用戶經過ANALYZE TABLE已擴展爲接受兩個新子句的語法建立直方圖：UPDATE HISTOGRAM ON column [, column] [WITH n BUCKETS]和DROP HISTOGRAM ON column [, column]。桶的數量是可選的，默認值是100.直方圖統計信息存儲在字典表「column_statistics」中，可經過視圖訪問information_schema.COLUMN_STATISTICS。因爲JSON數據類型的靈活性，直方圖存儲爲JSON對象。ANALYZE TABLE 將根據表大小自動決定是否採樣基準表。它還將根據數據分佈和指定的桶數來決定是創建一個singleton仍是一個等高直方圖。在這裏能夠看到ErikFrøseth的博客文章。

經常使用表達

MySQL的8.0支持UTF8MB4正則表達式，以及像新的功能REGEXP_INSTR()，REGEXP_LIKE()，REGEXP_REPLACE()，和REGEXP_SUBSTR()。已經添加了系統變量regexp_stack_limit（默認32步）和regexp_time_limit（默認8000000字節）來控制執行。該REGEXP_REPLACE() 功能是MySQL社區最須要的功能之一，例如，請參閱由Hans Ginzel 報告BUG＃27389的功能請求。另見馬丁漢森在這裏和博爾特馬裏烏斯約翰森在這裏的博客文章。

Dev Ops功能

Dev Ops關注數據庫的運營方面，一般涉及可靠性，可用性，性能，安全性，可觀察性和可管理性。高可用性附帶了MySQL InnoDB集羣和MySQL組複製，將由單獨的博客文章進行介紹。下面是8.0在其餘類別中帶來的東西。

可靠性

MySQL 8.0增長了MySQL的總體可靠性，由於：

MySQL 8.0將其元數據存儲到InnoDB中，這是一種久經考驗的事務性存儲引擎。系統表（如Users和Privileges以及Data Dictionary表）如今駐留在InnoDB中。

MySQL 8.0消除了潛在不一致的一個來源。在5.7和更早版本中，基本上有兩個數據字典，一個用於服務器層，另外一個用於InnoDB層，在某些崩潰的狀況下這些數據字典可能不一樣步。在8.0中只有一個數據字典。

MySQL 8.0確保原子的，崩潰安全的DDL。有了這個，用戶能夠保證任何DDL語句將被徹底執行或根本不執行。這在複製環境中尤其重要，不然可能會出現主節點和從節點（節點）不一樣步的狀況，從而致使數據漂移。

這項工做是在新的事務數據字典的背景下完成的。在這裏和這裏查看Staale Deraas的博客文章。

觀測

信息模式（加速）

MySQL 8.0從新實現了信息模式。在新的實現中，Information Schema表格是存儲在InnoDB中的數據字典表的簡單視圖。這比舊的實施效率高出100倍，效率更高。這使信息模式能夠經過外部工具實際使用。在這裏和這裏查看Gopal Shankar 的博客文章，以及StåleDeraas 在這裏的博客文章。

性能架構（加速）

MySQL 8.0經過在性能架構表上添加超過100個索引來加速性能架構查詢。性能架構表上的索引是預約義的。他們不能被刪除，添加或更改。性能模式索引是做爲對現有表數據的過濾掃描來實現的，而不是經過單獨的數據結構進行遍歷。沒有B樹或散列表須要構建，更新或以其餘方式管理。性能架構表索引在散列索引中的行爲以下：a）它們快速檢索所需的行，而且b）不提供行排序，並在必要時讓服務器對結果集進行排序。可是，根據查詢，索引能夠避免使用全表掃描，並返回至關小的結果集。性能模式索引可用SHOW INDEXES並在EXPLAIN輸出中表示引用索引列的查詢。見Simon Mudd的評論。在這裏查看Marc Alff的博文。

配置變量

MySQL的8.0增長了對配置變量，如變量名，有用的信息最小/最大值，這裏的電流值是從哪裏來的，誰進行了更改，並在它被作。該信息位於名爲的新性能模式表中 variables_info。在這裏能夠看到Satish Bharathy的博客文章。

客戶端錯誤報告 - 消息計數

MySQL 8.0能夠查看服務器報告的客戶端錯誤消息的聚合計數。用戶能夠查看來自5個不一樣表格的統計信息：全局計數，每一個線程的彙總，每一個用戶的彙總，每一個主機的彙總或每一個帳戶的彙總。對於每條錯誤消息，用戶均可以看到引起錯誤的數量，由SQL異常處理程序處理的錯誤數，「首次看到」時間戳和「上次看到」時間戳。給定正確的權限，用戶能夠SELECT從這些表TRUNCATE中重置統計信息。在這裏能夠看到Mayank Prasad的博客文章。

語句延遲柱狀圖

爲了更好地查看查詢響應時間，MySQL 8.0提供了語句延遲的性能模式直方圖。這項工做還從收集的直方圖中計算「P95」，「P99」和「P999」百分位數。這些百分比能夠用做服務質量的指標。見弗雷德裏克DESCAMPS博客文章在這裏。

數據鎖定相關性圖

MySQL 8.0儀器數據鎖定在性能模式中。當事務A鎖定R行，而且事務B在這個同一行上等待時，B被A有效阻止。添加的檢測揭示哪些數據被鎖定（R），誰擁有鎖（A），誰在等待數據（B）。見弗雷德裏克DESCAMPS博客文章在這裏。

摘要查詢示例

MySQL 8.0對events_statements_summary_by_digest性能模式表進行了一些更改，以捕獲完整的示例查詢和關於此查詢示例的一些關鍵信息。QUERY_SAMPLE_TEXT添加該列以捕獲查詢示例，以便用戶能夠在真實查詢上運行EXPLAIN並獲取查詢計劃。該列QUERY_SAMPLE_SEEN被添加以捕獲查詢樣本時間戳。該列QUERY_SAMPLE_TIMER_WAIT被添加以捕獲查詢樣本執行時間。列FIRST_SEEN和LAST_SEEN 已被修改成使用小數秒。見弗雷德裏克DESCAMPS博客文章在這裏。

有關儀器的元數據

MySQL 8.0將元數據（如屬性，易變性和文檔）添加到性能架構表 setup_instruments。這種只讀元數據可做爲儀器的在線文檔，供用戶或工具查看。見弗雷德裏克DESCAMPS博客文章在這裏。

錯誤記錄

MySQL 8.0對MySQL 錯誤日誌進行了重大改進。從軟件體系結構的角度來看，錯誤日誌是新服務基礎架構中的一個組件。這意味着高級用戶能夠根據須要編寫本身的錯誤日誌實現。大多數用戶不想編寫他們本身的錯誤日誌實現，但仍然但願在編寫和編寫它的地方有必定的靈活性。所以，8.0爲用戶提供設施來添加匯（哪裏）和過濾器（什麼）。MySQL 8.0實現了一個過濾服務（API）和一個默認的過濾服務實現（組件）。這裏的過濾意味着禁止給定日誌消息（投影）中的某些日誌消息（選擇）和/或字段。MySQL 8.0實現了日誌編寫器服務（API）和默認日誌編寫器服務實現（組件）。日誌編寫者接受日誌事件並將其寫入日誌。該日誌能夠是經典文件，syslog，EventLog和新的JSON日誌編寫器。

默認狀況下，沒有任何配置，MySQL 8.0提供了許多現成的錯誤日誌改進，例如：

錯誤編號：格式是10000系列中以「MY-」開頭的數字，例如「MY-10001」。GA版本中的錯誤編號將保持穩定，但在維護版本中容許相應的錯誤文本發生變化（即改進）。

系統消息：系統消息以[系統]而不是[錯誤]，[警告]，[注意]的形式寫入錯誤日誌。不管詳細狀況如何，都會打印[系統]和[錯誤]消息，且沒法取消。[系統]消息僅在少數地方使用，主要與主要狀態轉換相關，例如啓動或中止服務器。

減小詳細程度：log_error_verbosity的默認值從3（註釋）變爲2（警告）。這使得MySQL 8.0錯誤日誌在默認狀況下不會變得冗長。

源組件：每一個消息都用三個值[Server]，[InnoDB]，[Replic]中的一個註釋來顯示消息來自哪一個子系統。

這是啓動後寫入8.0 GA錯誤日誌的內容：

2018-03-08T10:14:29.289863Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.5) starting as process 8063

2018-03-08T10:14:29.745356Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.

2018-03-08T10:14:29.765159Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.5' socket: '/tmp/mysql.sock' port: 3306 Source distribution.

2018-03-08T10:16:51.343979Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.5) Source distribution.

2018-03-08T10:14:29.289863Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.5) starting as process 8063

2018-03-08T10:14:29.745356Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.

2018-03-08T10:14:29.765159Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.5' socket: '/tmp/mysql.sock' port: 3306 Source distribution.

2018-03-08T10:16:51.343979Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.5) Source distribution.

在錯誤日誌中引入錯誤編號可讓MySQL在即將發佈的維護版本（若是須要）中改進錯誤文本，同時保持錯誤編號（ID）不變。錯誤編號也是過濾/壓制和國際化/本地化的基礎。

可管理性

INVISIBLE索引

MySQL 8.0增長了切換索引可見性（可見/不可見）的功能。優化器在執行查詢執行計劃時不會考慮不可見索引。可是，該指數仍保留在後臺，所以再次顯示該指標很是便宜。這樣作的目的是讓DBA / DevOp肯定是否能夠刪除索引。若是您懷疑沒有使用索引，則首先使其不可見，而後監視查詢性能，若是沒有遇到查詢減慢的狀況，最後刪除索引。不少用戶都要求這個功能，例如Bug＃70299。請參閱Martin Hansson 在這裏發表的博文。

靈活撤消表空間管理

MySQL 8.0爲用戶提供了徹底控制撤消表空間的能力，例如，有多少個表空間，它們放置在哪裏以及每一個表空間的回滾段數。

再也不有撤消登陸系統表空間。撤消日誌在升級過程當中從系統表空間遷移到撤消表空間。這爲使用用於撤消日誌的系統表空間的現有5.7安裝提供了升級路徑。

撤銷表空間能夠與系統表空間分開管理。例如，撤消表空間能夠放在快速存儲上。

回收異常大型交易佔用的空間（在線）。建立至少兩個撤銷表空間以容許表空間截斷。這容許InnoDB收縮撤消表空間，由於一個撤消表空間能夠被激活而另外一個被截斷。

更多的回滾段致使爭用更少。用戶可能會選擇最多127個撤消表空間，每一個表空間最多有128個回滾段。更多的回滾段意味着併發事務更可能爲其撤消日誌使用單獨的回滾段，從而減小對相同資源的爭用。

在這裏查看凱文劉易斯的博客文章。

SET PERSIST用於全局變量

MySQL 8.0使持久化全局動態服務器變量成爲可能。許多服務器變量都是GLOBAL和DYNAMIC，能夠在服務器運行時從新配置。例如：SET GLOBAL sql_mode='STRICT_TRANS_TABLES'; 可是，從新啓動服務器時會丟失這些設置。

這項工做使得寫入成爲可能SET PERSIST sql_mode='STRICT_TRANS_TABLES'; 的結果是，該設置將在服務器從新啓動後存活。該功能有許多使用場景，但最重要的是，它提供了一種管理服務器設置的方法，當編輯配置文件不方便或不可選時。例如，在某些託管環境中，您不具備文件系統訪問權限，您擁有的只是可以鏈接到一臺或多臺服務器。至於SET GLOBAL你須要超級特權SET PERSIST。

還有RESET PERSIST命令。該RESET PERSIST命令具備從持久配置中除去配置變量的語義，從而將其轉換爲具備與之相似的行爲SET GLOBAL。

MySQL 8.0容許SET PERSIST設置大多數只讀變量，新值將在下次服務器重啓時生效。請注意，只有一小部分只讀變量是故意不可設置的。在這裏能夠看到Satish Bharathy的博客文章。

遠程管理

MySQL 8.0實現了一個SQL RESTART命令。目的是經過SQL鏈接啓用MySQL服務器的遠程管理，例如經過SET PERSIST後面的a 來設置非動態配置變量RESTART。查看博客文章 MySQL 8.0：輕鬆更改配置和雲端友好！由FrédéricDescamps提供。

重命名錶空間（SQL DDL）

MySQL 8.0實現ALTER TABLESPACE s1 RENAME TO s2;共享/常規表空間是一個用戶可見的實體，用戶能夠經過該實體建立，修改和刪除。請參閱錯誤＃26949，錯誤＃32497和錯誤＃58006。

重命名列（SQL DDL）

MySQL 8.0實現ALTER TABLE ... RENAME COLUMN old_name TO new_name;這是對現有語法ALTER TABLE <table_name> CHANGE ...的改進，它須要從新指定列的全部屬性。舊的/現有的語法的缺點是全部的列信息可能沒法用於嘗試重命名的應用程序。舊/現有語法中的意外數據類型更改也有可能致使數據丟失的風險。

安全功能

新的默認身份驗證插件

MySQL 8.0將默認身份驗證插件從mysql_native_password更改成caching_sha2_password。相應地，libmysqlclient也會使用caching_sha2_password做爲默認的認證機制。新的caching_sha2_password結合了更高的安全性（SHA2算法）和高性能（緩存）。總的方向是咱們建議全部用戶在他們的全部網絡通訊中使用TLS / SSL。在這裏能夠看到Harin Vadodaria的博客文章。

Community Edition中的默認OpenSSL

MySQL 8.0在OpenSSL上統一爲MySQL企業版和MySQL社區版的默認TLS / SSL庫。之前，MySQL社區版使用YaSSL。在MySQL Community Edition中支持OpenSSL一直是最經常使用的功能之一。見弗雷德裏克DESCAMPS博客文章在這裏。

OpenSSL是動態連接的

MySQL 8.0與OpenSSL動態連接。從MySQL Repository用戶的角度來看，MySQL包依賴於Linux系統提供的OpenSSL文件。經過動態連接，能夠在不須要MySQL升級或補丁的狀況下應用OpenSSL更新。見弗雷德裏克DESCAMPS博客文章在這裏。

撤消和重作日誌的加密

MySQL 8.0實現了UNDO和REDO日誌的靜態數據加密。在5.7中，咱們引入了存儲在每一個表文件表空間中的InnoDB表的表空間加密。此功能爲物理表空間數據文件提供靜態加密。在8.0中，咱們將其擴展爲包括UNDO和REDO日誌。在這裏看到文檔。

SQL角色

MySQL 8.0實現SQL角色。角色是指定的特權集合。目的是簡化用戶訪問權限管理。能夠爲用戶授予角色，授予角色權限，建立角色，刪除角色以及決定會話期間適用的角色。見弗雷德裏克DESCAMPS博客文章在這裏。

容許授予和撤銷PUBLIC

MySQL 8.0引入了配置變量mandatory-roles，能夠在建立新用戶時用於自動分配和授予默認角色。例如：。全部指定的角色老是被視爲授予每一個用戶，他們不能被撤銷。除非將這些角色設爲默認角色，不然這些角色仍須要激活。當新服務器配置變量設置爲「ON」時，全部受權角色始終在用戶經過身份驗證後激活。role1@%,role2,role3,role4@localhostactivate-all-roles-on-login

打破超級特權

MySQL 8.0爲之前版本中使用的SUPER的各個方面定義了一組新的粒度特權。目的是限制用戶對手頭工做所須要的訪問權限，僅此而已。例如BINLOG_ADMIN，CONNECTION_ADMIN和ROLE_ADMIN。

管理XA事務的受權模型

MySQL 8.0引入了一個新的系統特權XA_RECOVER_ADMIN來控制執行語句的能力XA RECOVER。XA RECOVER未被授予新系統特權的用戶所作的嘗試XA_RECOVER_ADMIN將致使錯誤。

密碼輪換政策

MySQL 8.0引入了密碼重用的限制。能夠在全局級別以及單個用戶級別配置限制。密碼歷史保持安全，由於它可能會提供有關我的用戶更改密碼時使用的習慣或模式的線索。該密碼輪換政策來除了其餘現有機制，如密碼過時策略和容許的密碼策略。請參閱密碼管理。

減緩用戶密碼的暴力攻擊

基於連續不成功的登陸嘗試，MySQL 8.0在認證過程當中引入了延遲。目的是減緩對用戶密碼的暴力攻擊。能夠配置延遲引入以前的連續不成功嘗試的次數，以及引入的最大延遲量。

退休跳過授予表

服務器啓動時，MySQL 8.0不容許遠程鏈接–skip-grant-tables。參見Omar Bourja報告的Bug＃ 79027。

將mysqld_safe功能添加到服務器

MySQL 8.0實現了當前在mysqld_safe服務器內腳本中找到的部分邏輯。這些工做提升了服務器的可用性，例如在使用--daemonize啓動選項時。這項工做還使用戶對mysqld_safe script咱們但願在將來消除的依賴性減小。它還修復了Peter Laursen報告的Bug＃75343。

性能

MySQL 8.0具備更好的讀/寫工做負載，IO綁定工做負載和高爭用「熱點」工做負載的性能。此外，新的資源組功能爲用戶提供了一個選項，能夠經過將用戶線程映射到CPU來針對特定硬件上的特定工做負載進行優化。

擴展讀/寫工做負載

MySQL 8.0在RW和繁重的寫入工做負載上能夠很好地擴展。在密集RW工做負載上，咱們觀察到來自4個併發用戶的性能更好，與MySQL 5.7相比，在高負載狀況下性能提升了2倍以上。咱們能夠說，雖然5.7只讀工做負載的可伸縮性顯着提升，但8.0顯着提升了讀/寫工做負載的可伸縮性。其效果是MySQL提升了標準服務器端硬件（如帶有2個CPU插槽的系統）的硬件利用率（效率）。這種改進是因爲從新設計InnoDB如何寫入REDO日誌。與用戶線程不斷努力記錄其數據更改的歷史實現相比，在新的REDO日誌解決方案中，用戶線程如今是無鎖的，REDO寫入和刷新由專用後臺線程管理，整個REDO處理變爲事件驅動。請參閱Dimitri Kravtchuk的博客文章這裏。

利用IO容量（快速存儲）

MySQL 8.0容許用戶使用每一個存儲設備的所有功能。例如，使用英特爾Optane閃存設備進行測試，咱們可以在徹底IO界限工做負載下超出1M點選QPS。（IO界限意味着數據不緩存在緩衝池中，但必須從輔助存儲中檢索）。這種改進是因爲擺脫了 fil_system_mutex全局鎖定。

高競爭負載下性能更佳（「熱門行」）

MySQL 8.0顯着提升了高爭用工做負載的性能。當多個事務正在等待表中同一行上的鎖定時，會發生較高的爭用工做負載，從而致使等待事務隊列。許多真實世界的工做量在一天中並不平滑，但可能會在特定時間爆發（帕累託分佈式）。不管是在每秒事務處理時間，平均延遲時間和第95百分位延遲方面，MySQL 8.0的處理都要好得多。因爲系統須要較少的備用容量，所以能夠以較高的平均負載運行，所以對最終用戶的好處是更好的硬件利用率（效率）。最初的補丁由Jiamin Huang提供（Bug＃84266）。請研究Contention-Aware事務調度（CATS）算法，並在此處閱讀Jiamin Huang和Sunny Bains撰寫的MySQL博客文章。

資源組

MySQL 8.0引入了全球資源組到MySQL。經過資源組，DevOps / DBA能夠管理用戶/系統線程和CPU之間的映射。這可用於跨CPU分割工做負載，以在某些使用狀況下得到更高的效率和/或性能。所以，資源組向DBA工具箱添加了一個工具，該工具能夠幫助DBA增長硬件利用率或提升查詢穩定性。例如，經過在英特爾（R）至強®CPU E7-4860 2.27 GHz 40核心-HT盒上運行的Sysbench RW工做負載，經過將寫入負載限制爲10個內核，咱們使總體吞吐量翻了一番。資源組是一個至關先進的工具，須要熟練的DevOps / DBA纔能有效使用，由於效果會隨着負載類型和手頭硬件而變化。

其餘特性

更好的默認值

在MySQL團隊中，咱們密切關注MySQL的默認配置，旨在爲用戶提供最佳的現成體驗。MySQL 8.0將30多個默認值更改成咱們認爲更好的值。請參閱博客文章MySQL 8.0中的New Defaults。Mogan Tocker 在博客文章中概述了這一動機。

協議

MySQL 8.0添加了一個選項來關閉結果集的元數據生成和傳輸。構造/解析和發送/接收結果集元數據會消耗服務器，客戶端和網絡資源。在某些狀況下，元數據大小可能比實際結果數據大小大得多，元數據不須要。咱們能夠經過徹底禁用這些數據的生成和存儲來顯着加快查詢結果傳輸速度。客戶能夠設置CLIENT_OPTIONAL_RESULTSET_METADATA標誌，若是他們不但願元數據返回結果集。

C客戶端API

MySQL 8.0經過一個穩定的接口擴展了libmysql的C API，以便從服務器獲取做爲數據包流的複製事件。目的是爲了不必須調用未記錄的API並打包內部頭文件以實現基於binlog的程序，例如Hadoop的MySQL Applier。

Memcached的

MySQL 8.0經過多個獲取操做並支持範圍查詢來加強InnoDB Memcached功能。咱們添加了對多重get操做的支持，以進一步提升讀取性能，即用戶能夠在單個memcached查詢中獲取多個鍵值對。Yoshinori @ Facebook已經要求支持範圍查詢。經過範圍查詢，用戶能夠指定特定的範圍，並獲取該範圍內的全部合格值。這兩個功能均可以顯着減小客戶端和服務器之間往返的次數。

持久的自動計數器

MySQL 8.0 AUTOINC經過將計數器寫入重作日誌來保留計數器。這是一個很老的Bug＃199的修復程序。MySQL恢復過程將重播重作日誌並確保AUTOINC計數器的值正確。不會有任何AUTOINC計數器回滾。這意味着數據庫恢復將在崩潰後從新創建最新的已知計數器值。它帶有保證AUTOINC計數器不能得到兩次相同的值。計數器單調遞增，但請注意可能存在空位（未使用的值）。缺少持久性AUTOINC在過去被視爲麻煩，例如，參見Stephen Dewey在2006年或本博客文章中報告的Bug＃21641。

參考：https://www.oschina.net/news/95325/mysql-8-0-ga-released?appinstall=0

http://www.sdbeta.com/wg/2018/0420/222014.html

轉載自：https://blog.csdn.net/zwj1030711290/article/details/80025981