MySQL 8.0有什麼新功能

時間 2019-11-29

標籤 mysql 8.0 什麼功能欄目 MySQL 简体版

原文原文鏈接

https://mysqlserverteam.com/whats-new-in-mysql-8-0-generally-available/php

咱們自豪地宣佈MySQL 8.0的通常可用性。如今下載！ MySQL 8.0是世界上最受歡迎的開源數據庫中使人興奮的新版本，而且全面改進。一些關鍵的加強功能包括：html

SQL 窗口函數，公用表表達式，NOWAIT和SKIP LOCKED，降序索引，分組，正則表達式，字符集，成本模型和直方圖。
JSON 擴展語法，新功能，改進的排序和部分更新。使用JSON表函數，您能夠將SQL機制用於JSON數據。
GIS 地理支持。空間參考系統（SRS），以及SRS感知空間數據類型，空間索引和空間函數。
可靠性 DDL語句已成爲原子和崩潰安全，元數據存儲在單個事務數據字典中。由InnoDB提供支持！
可觀察性 性能模式，信息模式，配置變量和錯誤記錄的顯着加強。
可管理性遠程管理，撤消表空間管理和新的即時DDL。
安全性 OpenSSL改進，新的默認身份驗證，SQL角色，分解超級權限，密碼強度等。
Performance InnoDB在讀/寫工做負載，IO綁定工做負載和高爭用「熱點」工做負載方面表現更佳。添加了資源組功能，經過將用戶線程映射到CPU，爲用戶提供了針對特定硬件上的特定工做負載進行優化的選項。

上面描述了一些亮點，我鼓勵你進一步深刻到完整的系列裏程碑博客文章-8.0.0的 8.0.1 ，8.0.2 ，8.0.3，and8.0.4 -和甚至進一步降低到各個工做日誌及其規格和實施細節。或者您可能只想查看github.com/mysql上的源代碼。mysql

開發者功能

MySQL開發人員須要新功能，MySQL 8.0在SQL，JSON，正則表達式和GIS等領域提供了許多新的和備受歡迎的功能。開發人員也但願可以存儲Emojis，所以UTF8MB4如今是8.0中的默認字符集。最後，數據類型有了改進，對BINARY數據類型進行了逐位操做，並改進了IPv6和UUID函數。git

SQL

窗口功能github

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 Wanvikhere的博客文章以及Guilhem Bichothere的博客文章。sql

公用表表達式數據庫

MySQL 8.0提供[遞歸]公用表表達式（CTE）。非遞歸CTE能夠解釋爲「改進的派生表」，由於它容許屢次引用派生表。遞歸CTE是一組迭代構建的行：從一組初始行開始，一個進程派生新行，這些行增加了這一組，並且這些新行再次被送入進程，產生更多行，依此類推，直到該過程再也不產生行。CTE是經常使用的SQL功能，請參閱功能請求 16244 和 32174 。查看Guilhem Bichothere的博客文章，這裏，這裏，和其餘地方。express

NOWAIT和SKIP LOCKED

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

降序索引

MySQL 8.0按降序提供對索引的支持。這種索引中的值按降序排列，咱們向前掃描。在8.0以前，當用戶建立降序索引時，咱們建立了一個升序索引並向後掃描它。一個好處是前向索引掃描比後向索引掃描更快。真正的降序索引的另外一個好處是它使咱們可以使用索引而不是filesort來處理ORDER BY 具備混合ASC/DESC 排序鍵部分的子句。降序索引是一種常常請求的SQL功能。參見例如特徵請求 13375 。請參閱Chaithra Gopalareddy的博客文章。

GROUPING

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

優化器提示

在5.7中，咱們爲優化器提示引入了一個新的提示語法。使用新語法，能夠SELECT | INSERT | REPLACE | UPDATE | DELETE 在SQL語句中的關鍵字以後直接指定提示，這些關鍵字包含在 /*+ */ 樣式註釋中。（見Sergey Glukhovhere的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 Glukhovhere的博客文章。

咱們更喜歡新格式的優化器提示，而不是舊式提示和值設置。經過不與SQL混合，能夠在查詢字符串中的許多位置注入新提示。它們在提示（vs指令）時也有更清晰的語義。optimizer_switch

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表函數，可使用SQL機制來處理JSON數據。 JSON_TABLE() 建立JSON數據的關係視圖。它將JSON數據評估的結果映射到關係行和列。用戶可使用SQL查詢函數返回的結果做爲常規關係表，例如join，project和aggregate。

JSON聚合函數

MySQL 8.0添加了聚合函數 JSON_ARRAYAGG() 來生成JSON數組並 JSON_OBJECTAGG() 生成JSON對象。這使得能夠將多行中的JSON文檔組合成JSON數組或JSON對象。請參閱Catalin Besleagahere的博客文章。

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 Tockerhere的博客文章。

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提供了邏輯差別，基於行的複製能夠經過線路發送並在從屬設備上從新應用。請參閱Knut Anders Hatlenhere的博客文章。

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_COLUMNS SQL / MM第3部分Sect中指定的視圖。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第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委員會於2016年6月21日宣佈的Unicode 9.0.0。
可用於latin1（MySQL遺留）的21種語言特定的不區分大小寫的排序規則已用於 utf8mb4 排序規則，例如捷克排序規則變爲utf8mb4_cs_800_ai_ci。請參閱WL＃9108中的完整列表。查看Xing Zhanghere的博客文章。
添加了對大小寫和重音敏感排序規則的支持。MySQL 8.0支持由DUCET（默認Unicode歸類條目表）定義的全部3級歸類權重。查看Xing Zhanghere的博客文章。
日語 utf8mb4_ja_0900_as_cs 整理，utf8mb4 使用三個級別的權重對字符進行排序。這爲日語提供了正確的排序順序。查看Xing Zhanghere的博客文章。
日語具備額外的假名敏感功能， utf8mb4_ja_0900_as_cs_ks 其中'ks'表明'假名敏感'。查看Xing Zhanghere的博客文章。
將全部新的排序規則從Unicode 9.0.0向前更改成， NO PAD 而不是 PAD STRING 像對任何其餘字符同樣處理字符串末尾的空格。這樣作是爲了提升一致性和性能。舊的整理留在原地。

另請參閱Bernt Marius Johnsenhere撰寫的博客文章。

數據類型

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

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地址並但願針對網絡掩碼進行測試，咱們如今可使用

INET6_ATON（地址）
 ＆INET6_ATON（網絡）

由於 INET6_ATON() 正確返回 VARBINARY(16) 數據類型（128位）。請參閱Catalin Besleagahere的博客文章。

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的缺點之一。請參閱Catalin Besleagahere的博客文章。

成本模型

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

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

優化器直方圖

MySQL 8.0實現了直方圖統計。使用直方圖，用戶能夠建立表中列的數據分佈統計信息，一般用於非索引列，而後查詢優化器將使用它來查找最佳查詢計劃。直方圖統計的主要用例是計算「COLUMN operator 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 將根據表大小自動決定是否對基表進行採樣。它還將根據數據分佈和指定的桶數決定是構建單例仍是等高直方圖。請參閱ErikFrøsethhere的博客文章。

經常使用表達

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的功能請求。另見Martin Hanssonhere和Bernt Marius Johnsenhere的博客文章。

Dev Ops功能

Dev Ops關注數據庫的操做方面，一般涉及可靠性，可用性，性能，安全性，可觀察性和可管理性。高可用性隨MySQL InnoDB Cluster和MySQL Group Replication一塊兒提供，這將由一篇單獨的博客文章介紹。如下是8.0對其餘類別的表格所帶來的內容。

可靠性

MySQL 8.0提升了MySQL的總體可靠性，由於：

MySQL 8.0將其元數據存儲到InnoDB中，這是一個通過驗證的事務存儲引擎。系統表（如用戶和權限以及數據字典表）如今位於InnoDB中。
MySQL 8.0消除了潛在不一致的一個來源。在5.7及更早版本中，基本上有兩個數據字典，一個用於服務器層，另外一個用於InnoDB層，這些字典在某些崩潰狀況下可能不一樣步。在8.0中只有一個數據字典。
MySQL 8.0確保原子，崩潰安全的DDL。有了這個，用戶能夠保證任何DDL語句均可以徹底執行或根本不執行。這在複製環境中尤爲重要，不然可能存在主設備和從設備（節點）不一樣步，致使數據漂移的狀況。

這項工做是在新的事務數據字典的上下文中完成的。查看Staale Deraashere andhere的博客文章。

觀測

信息架構（加速）

MySQL 8.0從新實現信息架構。在新實現中，信息模式表是存儲在InnoDB中的數據字典表的簡單視圖。這比舊的實現效率更高，速度提升了100倍。這使得信息模式實際上能夠經過外部工具使用。查看Gopal Shankarhere andhere的博客文章和StåleDeraashere的博客文章。

性能架構（加速）

MySQL 8.0經過在性能模式表上添加100多個索引來加速性能模式查詢。性能模式表的索引是預約義的。它們不能被刪除，添加或更改。性能模式索引實現爲跨現有表數據的過濾掃描，而不是經過單獨數據結構的遍歷。沒有要構建，更新或以其餘方式管理的B樹或哈希表。性能模式表索引的行爲相似於散列索引，其中a）它們快速檢索所需的行，b）不提供行排序，讓服務器在必要時對結果集進行排序。可是，根據查詢，索引會消除對全表掃描的須要，並返回至關小的結果集。性能模式索引是可見的 SHOW INDEXES 並在 EXPLAIN 輸出中表示引用索引列的查詢。來自Simon Mudd的評論。請參閱Marc Alffhere的博客文章。

配置變量

MySQL 8.0添加了有關配置變量的有用信息，例如變量名稱， 最小值/最大值 ，當前值來自何處，誰進行了更改以及什麼時候進行更改。此信息位於名爲的新性能模式表中 variables_info 。請參閱Satish Bharathyhere的博客文章。

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

MySQL 8.0能夠查看服務器報告的客戶端錯誤消息的聚合計數。用戶能夠查看來自5個不一樣表的統計信息：全局計數，每一個線程的摘要，每一個用戶的摘要，每一個主機的摘要或每一個賬戶的摘要。對於每一個錯誤消息，用戶能夠看到引起的錯誤數，SQL異常處理程序處理的錯誤數，「第一次看到」時間戳和「上次看到」時間戳。給定權限，用戶能夠 SELECT 從這些表 TRUNCATE 中重置統計信息。請參閱Mayank Prasadhere的博客文章。

聲明延遲直方圖

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.289863 ž 0 [系統] [MY- 010116 ] [服務器] / usr / sbin目錄/ mysqld的（mysqld的8.0。5）開始做爲過程8063 2018 -03-08T10：14：29.745356 ž 0 [警告] [ MY-010068 ] [服務器] CA證書ca.pem是自簽名的。 2018 -03-08T10：14：29.765159 Z 0 [系統] [ MY-010931 ] [服務器] / usr / sbin / mysqld：準備鏈接。版本：'8.0.5'   套接字：'/ tmp / mysql.sock'   端口：3306   源分發。 2018 -03-08T10：16：51.343979 ž 0 [系統] [MY- 010910 ] [服務器] / usr / sbin目錄/ mysqld的：關機完成（mysqld的8.0。5）來源的分佈。

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

可管理性

不可見的索引

MySQL 8.0增長了切換索引可見性（可見/不可見）的功能。優化程序在進行查詢執行計劃時不會考慮不可見索引。可是，索引仍然保留在後臺，所以再次顯示它很便宜。這樣作的目的是讓DBA / DevOp肯定是否能夠刪除索引。若是您懷疑某個索引未被使用，則首先使其不可見，而後監視查詢性能，最後在沒有遇到查詢減慢的狀況下刪除索引。許多用戶已經要求使用此功能，例如經過 Bug＃70299 。請參閱Martin Hanssonhere的博客文章。

靈活撤銷表空間管理

MySQL 8.0使用戶能夠徹底控制撤消表空間，即有多少表空間，它們放在哪裏，以及每一個表空間中有 多少個回滾段。

再也不在系統表空間中撤消登陸。 在升級期間，撤消日誌將從System表空間遷移到Undo表空間。這爲使用系統表空間的撤消日誌提供了現有5.7安裝的升級路徑。
撤消表空間能夠與System表空間分開管理。 例如，撤消表空間能夠放在快速存儲上。
回收很是大的交易所佔用的空間（在線）。 至少建立兩個Undo表空間以容許表空間截斷。這容許InnoDB縮小撤消表空間，由於一個撤消表空間能夠是活動的而另外一個是截斷的。
更多回滾段能夠減小爭用。 用戶可能選擇最多127個撤消表空間，每一個表空間最多包含128個回滾段。更多回滾段意味着併發事務更有可能爲其撤消日誌使用單獨的回滾段，從而減小對相同資源的爭用。

請參閱Kevin Lewishere的博客文章。

全局變量的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 命令具備從persist配置中刪除配置變量的語義，從而將其轉換爲具備相似的行爲 SET GLOBAL 。

MySQL 8.0容許 SET PERSIST 設置大多數只讀變量，新值將在下次服務器重啓時生效。請注意，有意沒法設置一小部分只讀變量。請參閱Satish Bharathyhere的博客文章。

遠程管理

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; 共享/通用表空間是用戶可見的實體，用戶可使用CREATE，ALTER和DROP。另請參閱 Bug＃26949 ， Bug＃32497 和 Bug＃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 Vadodariahere的博客文章。

社區版中的默認OpenSSL

MySQL 8.0統一在 OpenSSL上做爲MySQL企業版和MySQL社區版的默認TLS / SSL庫。之前，MySQL Community Edition使用 YaSSL 。在MySQL社區版中支持OpenSSL一直是最常請求的功能之一。請參閱FrédéricDescampshere的博客文章。

OpenSSL是動態連接的

MySQL 8.0與OpenSSL動態連接。從 MySQL Repository 用戶的角度來看，MySQL軟件包依賴於Linux系統提供的OpenSSL文件。經過動態連接，能夠在可用時應用OpenSSL更新，而無需MySQL升級或修補程序。請參閱FrédéricDescampshere的博客文章。

撤消和重作日誌的加密

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

SQL角色

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

容許PUBLIC的受權和撤銷

MySQL 8.0引入了配置變量，可用於在建立新用戶時自動分配和授予 默認角色。示例：。始終將全部指定的角色視爲已授予每一個用戶，而且沒法撤消這些角色。除非將這些角色設爲默認角色，不然這些角色仍須要激活。當新服務器配置變量設置爲「ON」時，在用戶進行身份驗證後，始終會激活全部授予的角色。 mandatory-roles 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基於連續不成功的登陸嘗試在認證過程當中引入了延遲。目的是減緩對用戶密碼的暴力攻擊。能夠在引入延遲以前配置連續不成功嘗試的次數以及引入的最大延遲量。

退出skip-grant-tables

啓動服務器時，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容許用戶充分利用每一個存儲設備。例如，使用Intel Optane閃存設備進行測試，咱們可以在徹底IO綁定的工做負載中超過1M Point-Select QPS。（IO綁定意味着數據不緩存在緩衝池中，但必須從輔助存儲中檢索）。這種改進是因爲擺脫了 fil_system_mutex 全球鎖定。

高爭用負載時的更好性能（「熱行」）

MySQL 8.0顯着提升了高爭用工做負載的性能。當多個事務正在等待表中同一行的鎖定時，會發生高爭用工做負載，從而致使等待事務的隊列。許多現實世界的工做負載不是平穩的，例如一天，但可能在某些時間爆發（帕累託分佈）。MySQL 8.0在每秒事務數，平均延遲和第95百分位延遲方面都能更好地處理此類突發事件。最終用戶的好處是更好的硬件利用率（效率），由於系統須要更少的備用容量，所以能夠以更高的平均負載運行。最初的補丁由Jiamin Huang（ Bug＃84266 ）提供。請研究一下爭用意識事務調度（CATS）算法，閱讀賈民明和Sunny Bainshere的MySQL博客文章。

資源組

MySQL 8.0將全局資源組引入MySQL。使用資源組，DevOps / DBA能夠管理用戶/系統線程和CPU之間的映射。這可用於在CPU之間拆分工做負載，以在某些用例中得到更高的效率和/或性能。所以，資源組向DBA工具箱添加了一個工具，該工具能夠幫助DBA提升硬件利用率或提升查詢穩定性。例如，在Intel（R）Xeon（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 Tockerhere在博客文章中概述了這一動機。

協議

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

C客戶端API

MySQL 8.0擴展了libmysql的C API，其中包含一個穩定的接口，用於從服務器獲取做爲數據包流的複製事件。目的是避免調用未記錄的API和打包內部頭文件，以實現基於binlog的程序，如MySQL Applier for Hadoop。

Memcached的

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

持久性自動計數器

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

摘要

如上所示，MySQL 8.0帶有大量新功能和性能改進。從dev.mysql.com下載並試用！

您還能夠將現有的MySQL 5.7 升級到MySQL 8.0。在此過程當中，您可能須要嘗試新的MySQL Shell（mysqlsh）附帶的newUpgrade Checker。此實用程序將分析您現有的5.7服務器並告訴您可能的8.0不兼容性。另外一個很好的資源是博客文章遷移到MySQL 8.0而不會破壞FrédéricDescamps的舊應用程序。

在這篇博文中，咱們介紹了服務器功能。還有更多！咱們還將發佈其餘功能的博客文章，例如複製，組複製，InnoDB羣集，文檔存儲，MySQL Shell，DevAPI和鏈接器。

這就是如今， 感謝您 使用 MySQL ！