原文：https://mysqlserverteam.com/whats-new-in-mysql-8-0-generally-available/

我們自豪地宣佈MySQL 8.0的一般可用性。現在下載！MySQL 8.0是全球最受歡迎的開源資料庫的一個非常令人興奮的新版本，全面改進。一些關鍵的增強包括：

1. SQL視窗函式，公用表表達式，NOWAIT和SKIP LOCKED，降序索引，分組，正則表示式，字符集，成本模型和直方圖。
2. JSON擴充套件語法，新功能，改進排序和部分更新。使用JSON表函式，您可以使用JSON資料的SQL機制。
3. GIS地理支援。空間參考系統（SRS），以及SRS感知空間資料型別，空間索引和空間功能。
4. 可靠性DDL語句已變得原子性和崩潰安全，元資料儲存在單個事務資料字典中。由InnoDB提供支援！
5. 可觀察性效能架構，資訊架構，配置變數和錯誤記錄的顯著增強。
6. 可管理性遠端管理，撤消表空間管理和新的即時DDL。
7. 安全OpenSSL改進，新的預設身份驗證，SQL角色，分解超級特權，密碼強度等等。
8. 效能InnoDB在讀/寫工作負載，IO繫結工作負載和高爭用“熱點”工作負載方面明顯更好。增加了資源組功能，通過將使用者執行緒對映到CPU，為使用者提供一個選項，以針對特定硬體上的特定工作負載進行優化

上面描述了一些亮點，我鼓勵你進一步深入到完整的系列裡程碑部落格posts-的8.0.0

，8.0.1，8.0.2，8.0.3和8.0.4-和甚至進一步向下個別工作日誌及其規格和實施細節。或者，您可能更願意檢視github.com/mysql上的原始碼。

開發者功能

MySQL開發人員需要新功能，而MySQL 8.0在諸如SQL，JSON，正則表示式和GIS等領域提供了許多新的和更多需求的功能。開發人員也希望能夠儲存Emojis，因此UTF8MB4現在是8.0中的預設字符集。最後，資料型別得到了改進，在BINARY資料型別上進行了按位操作，並改進了IPv6和UUID功能。

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在這裡發表的博文。

降序索引

MySQL 8.0按降序提供對索引的支援。這種索引中的值按降序排列，我們將其向前掃描。在8.0之前，當用戶建立降序索引時，我們建立了一個升序索引並向後掃描。一個好處是前向索引掃描比後向索引掃描快。真正的降序索引的另一個好處是，它使我們能夠使用索引而不是資料夾作為ORDER BY具有混合ASC/DESC排序關鍵部分的子句。降序索引是一個頻繁請求的SQL功能。請參閱功能請求13375。見Chaithra Gopalareddy部落格文章在這裡。

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.0JSON_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的UUIDVARBINARY(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的整體可靠性，因為：

1. MySQL 8.0將其元資料儲存到InnoDB中，這是一種久經考驗的事務性儲存引擎。系統表（如Users和Privileges以及Data Dictionary表）現在駐留在InnoDB中。
2. MySQL 8.0消除了潛在不一致的一個來源。在5.7和更早版本中，基本上有兩個資料字典，一個用於伺服器層，另一個用於InnoDB層，在某些崩潰的情況下這些資料字典可能不同步。在8.0中只有一個數據字典。
3. 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錯誤日誌的內容：

1 2 3 4

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: 3306Source 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為使用者提供了完全控制撤消表空間的能力，例如，有多少個表空間，它們放置在哪裡以及每個表空間的回滾段數。

1. 不再有撤消登入系統表空間。在升級過程中，撤銷日誌將從系統表空間遷移到撤消表空間中。這為使用用於撤消日誌的系統表空間的現有5.7安裝提供了升級路徑。
2. 撤銷表空間可以與系統表空間分開管理。例如，撤消表空間可以放在快速儲存上。
3. 回收異常大型交易佔用的空間（線上）。建立至少兩個撤銷表空間以允許表空間截斷。這允許InnoDB收縮撤消表空間，因為一個撤消表空間可以被啟用而另一個被截斷。
4. 更多的回滾段導致爭用更少。使用者可能會選擇最多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的處理都要好得多。由於系統需要較少的備用容量，因此可以以較高的平均負載執行，因此對終端使用者的好處是更好的硬體利用率（效率）。最初的補丁由JiaminHuang提供（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.0AUTOINC通過將計數器寫入重做日誌來保留計數器。這是一個很老的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）附帶的新升級檢查器。該實用程式將分析您現有的5.7伺服器並告訴您潛在的8.0不相容性。另一個很好的資源是遷移到MySQL 8.0的部落格文章，而不會破壞FrédéricDescamps的舊應用程式。

在這篇博文中，我們介紹了伺服器功能。還有更多！我們還將釋出其他功能（例如複製，組複製，InnoDB叢集，文件儲存，MySQL Shell，DevAPI和基於DevAPI的聯結器（聯結器/ Node.js，聯結器/ Python，PHP，聯結器/ NET，聯結器/ ODBC，聯結器/ C ++和聯結器/ J）。

這就是現在，並感謝您使用MySQL！