MySQL 8.0 正式版 8.0.11 已發布，官方表示 MySQL 8 要比 MySQL 5.7 快 2 倍，還帶來了大量的改進和更快的性能！
注意：從 MySQL 5.7 升級到 MySQL 8.0 僅支持通過使用 in-place 方式進行升級，並且不支持從 MySQL 8.0 降級到 MySQL 5.7（或從某個 MySQL 8.0 版本降級到任意一個更早的 MySQL 8.0 版本）。唯一受支持的替代方案是在升級之前對數據進行備份。
MySQL 8.0是全球最受歡迎的開源數據庫的一個非常令人興奮的新版本，全面改進。一些關鍵的增強包括：
SQL窗口函數，公用表表達式，NOWAIT和SKIP LOCKED，降序索引，分組，正則表達式，字符集，成本模型和直方圖。
JSON擴展語法，新功能，改進排序和部分更新。使用JSON表函數，您可以使用JSON數據的SQL機制。
GIS地理支持。空間參考系統（SRS），以及SRS感知空間數據類型，空間索引和空間功能。
可靠性 DDL語句已變得原子性和崩潰安全，元數據存儲在單個事務數據字典中。由InnoDB提供支持！
可觀察性性能架構，信息架構，配置變量和錯誤記錄的顯着增強。
可管理性遠程管理，撤消表空間管理和新的即時DDL。
安全 OpenSSL改進，新的默認身份驗證，SQL角色，分解超級特權，密碼強度等等。
性能 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功能。
下面簡要介紹 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 合規性。
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 在這里發表的博文。
降序索引
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.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.
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: 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://blog.csdn.net/zwj1030711290/article/details/80025981?utm_source=blogxgwz0