溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章將為大家詳細講解有關MySQL8.0 GA版本的新特性有哪些，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
非常高興的向大家宣布MySQL 8.0 GA版本發布，MySQL 8.0是一個得到全面增強且極具吸引力的新版本。不限于下面幾點：
SQL方面：窗口函數，公共表達式，NOWAIT,SKIPLOCKED,降序索引，分組，正則表達式，字符集，基于性能損耗的優化模式，直方圖
SQL Window functions, Common Table Expressions, NOWAIT and SKIP LOCKED, Descending Indexes, Grouping, Regular Expressions, Character Sets, Cost Model, and Histograms.
對JSON的支持：擴充語法，新功能，增強排序，部分更新性能，基于JSON表的特性，可以使用SQL處理工具處理JSON數據。
JSON Extended syntax, new functions, improved sorting, and partial updates. With JSON table functions you can use the SQL machinery for JSON data.
對地理信息系統的支持
GIS Geography support. Spatial Reference Systems (SRS), as well as SRS aware spatial datatypes, spatial indexes, and spatial functions.
可靠性：DDL語句現在實現原子性和故障恢復（元信息數據被存在了一個基于InnoDB的單獨事務性數據字典中）。
Reliability DDL statements have become atomic and crash safe, meta-data is stored in a single, transactional data dictionary. Powered by InnoDB!
可觀察性：對P_S,I_S,配置參數，錯誤日志的記錄有了極其重要的增強
Observability Significant enhancements to Performance Schema, Information Schema, Configuration Variables, and Error Logging.
可管理性：遠程管理，Undo表空間管理，快速DDL
Manageability Remote management, Undo tablespace management, and new instant DDL.
安全性：OpenSSL的改進，新的默認驗證方式，SQL角色權限，分解super權限，密碼強度等等
Security OpenSSL improvements, new default authentication, SQL Roles, breaking up the super privilege, password strength, and more.
性能：InnoDB在讀寫，帶寬限制，業務熱數據集中的場景上上有著舉足輕重的優點，新增的資源組特性額外給用戶一個在特定負載和特定硬件情況下將用戶線程映射到指定的CPU上的調節選項
Performance InnoDB is significantly better at Read/Write workloads, IO bound workloads, and high contention “hot spot” workloads. Added Resource Group feature to give users an option optimize for specific workloads on specific hardware by mapping user threads to CPUs.
以上是8.0版本的部分亮點，我（原文作者）推薦您仔細閱讀GA版本前幾個版本的發布信息，甚至這些特性和實現方法的的項目日志。或者您可以選擇直接在Github上閱讀源碼。
MySQL 8.0應面向MySQL開發人員的需求，帶來了SQL，JSON，公共表達式，地理信息系統等方面的特性，因為很多開發人員有存儲EmoJi表情的需求，在新版本中UTF8MB4成為默認的字符集。除此之外，還有對Binary數據類型按位操作，和改進對IPV6和UUID函數的改進。
MySQL 8.0帶來了標準SQL的窗口函數功能，窗口函數與分組聚合函數相類似的是都提供了對一組行數據的統計計算。但與分組聚合函數將多行合并成一行不同是窗口函數會在結果結果集中展現每一行的聚合。
窗口函數有兩種使用方式，首先是常規的SQL聚合功能函數和特殊的窗口函數。常規的聚合功能函數如：COUNT,SUM等函數。而窗口函數專有的則是RANK, DENSE_RANK, PERCENT_RANK, CUME_DIST, NTILE, ROW_NUMBER, FIRST_VALUE, LAST_VALUE, NTH_VALUE, LEADand LAG等函數
對窗口函數的支持上，是用戶呼聲比較頻繁。窗口函數早在SQL2003規范中就成為了標準SQL的一部分。
Support for window functions (a.k.a. analytic functions) is a frequent user request. Window functions have long been part of standard SQL (SQL 2003). See blog post by Dag Wanvik here as well as blog post by Guilhem Bichot here.
MySQL 8.0 帶來了支持遞歸的公用表達式的功能。非遞歸的公用表達式由于允許由form子句派生的臨時表的原因可以被多次引用，因而被解釋為改進型的派生表（from子句中的臨時表）。而遞歸的公用表達式則由一組原始住居，經過處理后得到新的一組數據，再被帶入處理得到更多的新數據，循環往復直到再也無法產生更多新數據為止。公用表達式也是一個用戶呼聲頻繁的SQL功能。
MySQL 8.0 給SQL的上鎖子句帶來了NOWAIT和SKIP LOCKED兩個額外的可選項。在原來的版本中，當行數據被UPDATE或者SELECT ... FOR UPDATE語句上鎖后，其他的事務需要等待鎖釋放才能訪問這行數據。但在某些場景下，有著要馬上獲取反饋的（不等待鎖）需求。使用NOWAIT參數后如果請求的數據中包括了被鎖住的行，將馬上會收到查詢失敗的報錯信息。使用SKIP LOCKED參數后，返回的數據將會跳過被鎖住的行。
MySQL 8.0 帶來了對降序索引的支持。在 8.0降序索引中，數據被倒序組織，正向查找。而在之前的版本中，雖然支持創建降序排列的索引，但其實現方式是通過創建常見的正序索引，然后進行反向查找來實現的。一方面來說，正序查找要比逆序查找更快，另一方面來說，真正的降序索引在復合的order by語句（即有asc又有desc）中,可以提高索引利用率，減少filesort。
MySQL 8.0 帶來了GROUPING()分組函數，這個功能可以把group by子句的擴展功能（如ROLLUP）產生的過聚合的NULL值，通過0和1進行區分，1為NULL，這樣就可以在having子句中對過聚合的無效值進行過濾。
在5.7版本中我們引入了新的優化器建議的語法，借助這個新的語法，優化器建議可以被用/*+ */包裹起來直接放在SELECT | INSERT | REPLACE | UPDATE | DELETE關鍵字的后面。在8.0的版本中我們又加入了新的姿勢。
In 5.7 we introduced a new hint syntax for optimizer hints. With the new syntax, hints can be specified directly after the SELECT | INSERT | REPLACE | UPDATE | DELETEkeywords in an SQL statement, enclosed in /*+ */ style comments. (See 5.7 blog post by Sergey Glukhov here). In MySQL 8.0 we complete the picture by fully utilizing this new style:
8.0版本增加了INDEX_MERGE和NO_INDEX_MERGE,允許用戶在單個查詢中控制是否使用索引合并特性。
MySQL 8.0 adds hints for INDEX_MERGE and NO_INDEX_MERGE. This allows the user to control index merge behavior for an individual query without changing the optimizer switch.
8.0版本增加了JOIN_FIXED_ORDER, JOIN_ORDER, JOIN_PREFIX, 和 JOIN_SUFFIX，允許用戶控制join表關聯的順序。
MySQL 8.0 adds hints for JOIN_FIXED_ORDER, JOIN_ORDER, JOIN_PREFIX, and JOIN_SUFFIX. This allows the user to control table order for the join execution.
8.0版本增加了SET_VAR，該優化器建議可以設定一個只在下一條語句中生效的的系統參數。
MySQL 8.0 adds a hint called SET_VAR. The SET_VAR hint will set the value for a given system variable for the next statement only. Thus the value will be reset to the previous value after the statement is over. See blog post by Sergey Glukhov here.
相對于之前的優化器建議和優化器特性開關參數，我們更傾向于推薦新形式的優化器建議，新形式的優化器建議可以在不侵入SQL語句（指修改語句的非注釋的業務部分）的情況下，注入查詢語句的很多位置。與直接修改語句的優化器建議相比，新形勢的優化器建議在SQL語義上更加清晰。
8.0版本追加了新的JSON函數，并可以提高在排序與分組JSON數據情況下的性能。
MySQL 8.0 adds new JSON functions and improves performance for sorting and grouping JSON values.
MySQL 8.0 擴展了JSON path表達式中范圍性的語法，比如：SELECT JSON_EXTRACT('[1, 2, 3, 4, 5]', '$[1 to 3]');可以得出[2, 3, 4]的結果
MySQL 8.0 extends the syntax for ranges in JSON path expressions. For example SELECT JSON_EXTRACT('[1, 2, 3, 4, 5]', '$[1 to 3]'); results in [2, 3, 4]. The new syntax introduced is a subset of the SQL standard syntax, described in SQL:2016, 9.39 SQL/JSON path language: syntax and semantics. See also Bug#79052reported by Roland Bouman.
MySQL 8.0 增加了可以在JSON數據上使用SQL處理工具的JSON 表函數。JSON_TABLE()函數可以創建JSON數據的關系型視圖。可以將JSON數據估算到關系型的行列之中，用戶可以對此函數返回的數據按照常規關系型數據表的方式進行SQL運算。
MySQL 8.0 adds JSON table functions which enables the use of the SQL machinery for JSON data. JSON_TABLE() creates a relational view of JSON data. It maps the result of a JSON data evaluation into relational rows and columns. The user can query the result returned by the function as a regular relational table using SQL, e.g. join, project, and aggregate.
MySQL 8.0 增加了用于生成JSON陣列的聚合函數JSON_ARRAYAGG()，和用于生成JSON對象的JSON_OBJECTAGG()函數，令多行的JSON文檔組合成JSON陣列或者JSON對象成為可能。
MySQL 8.0 adds the aggregation functions JSON_ARRAYAGG() to generate JSON arrays and JSON_OBJECTAGG() to generate JSON objects . This makes it possible to combine JSON documents in multiple rows into a JSON array or a JSON object. See blog post by Catalin Besleaga here.
JSON_MERGE_PATCH() 函數可執行JavaScript的語法，在合并時發生重復鍵值對時將會優先選用第二個文檔的鍵值對，并刪除第一個文檔對應的重復鍵值。
The JSON_MERGE_PATCH() function implements the semantics of JavaScript (and other scripting languages) specified by RFC7396, i.e. it removes duplicates by precedence of the second document. For example, JSON_MERGE('{"a":1,"b":2 }','{"a":3,"c":4 }');# returns {"a":3,"b":2,"c":4}.
JSON_MERGE_PRESERVE()函數與5.7版本中的JSON_MERGE()含義相同，都是在合并的時候保留所有值。
The JSON_MERGE_PRESERVE() function has the semantics of JSON_MERGE() implemented in MySQL 5.7 which preserves all values, for example JSON_MERGE('{"a": 1,"b":2}','{"a":3,"c":4}'); # returns {"a":[1,3],"b":2,"c":4}.
5.7原來的JSON_MERGE() 函數在8.0版本中為減少merge操作的不明確，而被棄用。
8.0版本增加了可以接收JSON原生數據類型和字符串表達的JSON，并返回一行縮進的易讀的JSON格式化后的的字符串。
8.0版本增加了和指定JSON對象空間占用相關的函數，JSON_STORAGE_SIZE() 可以用字節為單位返回JSON某個數據類型的實際大小， JSON_STORAGE_FREE() 可以返回該JSON數據類型的剩余空間（包括碎片和用來適應更改后發生長度變化的預備空間）
8.0版本通過使用變長的排序鍵提升了JSON排序分組的性能。在某些場景下，Preliminary 的壓測結果出現了1.2到18倍的提升。
MySQL 8.0 gives better performance for sorting/grouping JSON values by using variable length sort keys. Preliminary benchmarks shows from 1.2 to 18 times improvement in sorting, depending on use case.
8.0版本增加了對 JSON_REMOVE(), JSON_SET() and JSON_REPLACE() 函數的部分更新的支持。如果JSON文檔的某部分被更新，我們會將更改的詳情給到句柄。這樣存儲引擎和復制關系就不必寫入整個JSON文檔。在之前的復制環境中由于無法確保JSON文檔的排列(layout)在主從上完全一致，所以在基于行的復制情況下物理文件的差異并不能用來削減傳輸復制信息帶來的網絡IO消耗。因此，8.0版本提供了在邏輯上區分差異的方法，可以在行復制的情況下傳輸并應用到從庫上
8.0 版本提供對地形的支持，其中包括了對空間參照系的數據源信息的支持，SRS aware spatial數據類型，空間索引，空間函數。總而言之，8.0版本可以理解地球表面的經緯度信息，而且可以在任意受支持的5000個空間參照系中計算地球上任意兩點之間的距離。
ST_SPATIAL_REFERENCE_SYSTEMS 存在于information schema視圖庫中，提供了可供使用的SRS坐標系統的名稱。每個SRS坐標系統都有一個SRID編號。8.0版本支持EPSG Geodetic Parameter Dataseset中的5千多個坐標系統（包括立體模和2D平面地球模型）
空間類的數據類型可以直接從SRS坐標系統的定義中獲取，例如：使用SRID 4326定義進行建表： CREATE TABLE t1 (g GEOMETRY SRID 4326); 。SRID是適用于地理類型的數據類型。只有同一SRID的的數據才會被插入到行中。與當前SRID數據類型的數據嘗試插入時，會報錯。未定義SRID編號的表將可以接受所有SRID編號的數據。
8.0版本增加了 INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS 視圖，可以顯示當前實例中所有地理信息的數據行及其對應的SRS名稱，編號，地理類型名稱。
MySQL 8.0 adds the INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS view as specified in SQL/MM Part 3, Sect. 19.2. This view will list all GEOMETRY columns in the MySQL instance and for each column it will list the standard SRS_NAME , SRS_ID , and GEOMETRY_TYPE_NAME.
在空間數據類型上可以創建空間索引，創建空間索引的列必須非空，例如： CREATE TABLE t1 (g GEOMETRY SRID 4326 NOT NULL, SPATIAL INDEX(g));
Spatial indexes can be created on spatial datatypes. Columns in spatial indexes must be declared NOT NULL. For example like this: CREATE TABLE t1 (g GEOMETRY SRID 4326 NOT NULL, SPATIAL INDEX(g));
創建空間索引的列必須具有SRID數據標識以用于優化器使用，如果將空間索引建在沒有SRID數據標識的列上，將輸出waring信息。
8.0 增加了諸如 ST_Distance() 和 ST_Length() 等用于判斷數據的參數是否在SRS中，并計算其空間上的距離。到目前為止，ST_Distance和其他的空間關系型函數諸如ST_Within,ST_Intersects,ST_Contains,ST_Crosses都支持地理計算。其運算邏輯與行為參見 SQL/MM Part 3 Spatial
8.0版本默認使用UTF8MB4作為默認字符集。相比較5.7版本，SQL性能（諸如排序UTF8MB4字符串）得到了很大的提升。UTF8MB4類型在網頁編碼上正占據著舉足輕重的地位，將其設為默認數據類型后，將會給絕大多數的MySQL用戶帶來遍歷。
默認的字符集從latin1變為 utf8mb4 ,默認排序校對規則從 latin1_swedish_ci 變為utf8mb4_800_ci_ai。
utf8mb4同樣也成為libmysql，服務端命令行工具,server層的默認編碼
utf8mb4同樣也成為MySQL測試框架的默認編碼
排序校對規則的權重與大小寫基于Unicode委員會16年公布的Unicode 9.0.0版本。
在以往的MySQL版本中，latin1編碼中的21種語言的特殊大小寫和排序校對規則被引入了 utf8mb4 排序校對規則。例如：捷克語的排序校對規則變成了utf8mb4_cs_800_ai_ci。
增加了對特殊語境和重音敏感的排序校對規則的支持。8.0版本支持 DUCET (Default Unicode Collation Entry Table)全部三級排序校對規則。
utf8mb4 的 utf8mb4_ja_0900_as_cs 排序校驗規則對日語字符支持三級權重的排序。
對日語有額外的假名支持特性， utf8mb4_ja_0900_as_cs_ks中的ks表示假名區分。
把 Unicode 9.0.0之前所有排序校驗規則中的不填補變成填補字符，此舉有利于提升字符串的一致性和性能。例如把字符串末尾的空格按照其他字符對待。之前的排序校驗規則在處理這種情況時保留字符串原樣。
8.0版本擴展了 bit-wise操作（如bit-wise AND等）的使用范圍，使得其在所有 BINARY 數據類型上都適用。在此之前只支持整型數據，若強行在二進制數據類型上使用Bit-wise操作，將會隱式轉換為64位的BITINT類型，并可能丟失若干位的數據。從8.0版本之后，bit-wise操作可以在 BINARY 和BLOB類型上使用，且不用擔心精確度下降的問題。
8.0版本通過支持 BINARY 上的Bit-wise操作提升了IPv6數據的可操作性。5.6版本中引入了支持IPv6地址和16位二進制數據的互相轉換的INET6_ATON() 和 INET6_NTOA() 函數。但是直到8.0之前，由于上一段中的問題我們都無法講IPv6轉換函數和bit-wise操作結合起來。由于 INET6_ATON() 可以正確的返回128bit的VARBINARY(16)，如果我們想要將一個IPv6地址與網關地址進行比對，現在就可以使用 INET6_ATON(address)& INET6_ATON(network) 操作。
8.0版本通過增加了三個新的函數（UUID_TO_BIN(), BIN_TO_UUID(), 和 IS_UUID()）提升了UUID的可用性。UUID_TO_BIN()可以將UUID格式的文本轉換成VARBINARY(16), BIN_TO_UUID()則與之相反， IS_UUID()用來校驗UUID的有效性。將UUID以 VARBINARY(16) 的方式存儲后，就可以使用實用的索引了。 UUID_TO_BIN() 函數可以原本轉換后的二進制數值中的時間相關位（UUID生成時有時間關聯）移到數據的開頭，這樣對索引來說更加友好而且可以減少在B樹中的隨機插入，從而減少了插入耗時。
8.0版本自動地根據數據是否存在于內存中而選擇查詢計劃，在以往的版本中，消耗敏感的模型始終假設數據在磁盤上。正因為現在查詢內存數據和查詢硬盤數據的消耗常數不同，因此優化器會根據數據的位置選擇更加優化的讀取數據方式。
8.0版本加入了直方圖統計數據。用戶可以根據直方圖針對表中的某列（一般為非索引列）生成數據分布統計信息，這樣優化器就可以利用這些信息去尋覓更加優化的查詢計劃。直方圖最常見的使用場景就是計算字段的選擇性。
用以創建直方圖的 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命令會自動的判斷是否要表進行采樣，甚至會根據表中數據的分布情況和統計總量來決定創建等頻或者等高的直方圖。
與UTF8MB4的正則支持一同，8.0版本也增加了諸如 REGEXP_INSTR(), REGEXP_LIKE(), REGEXP_REPLACE(), 和REGEXP_SUBSTR()等新函數。另外，系統中還增加了用以控制正則表達式致性的 regexp_stack_limit (默認8000000比特) 和 regexp_time_limit (默認32步) 參數。REGEXP_REPLACE()也是社區中受呼聲比較高的特性。
開發向的運維關心數據庫實例的可操作型，通常即可靠性，可用性，性能，安全，可觀測性，可管理性。關于InnoDB Cluster和MGR的可靠性我們將會另起新篇單獨介紹，接下來的段落將會介紹關于8.0版本針對表在其他可操作性上的改變。
8.0版本在整體上 增加了可靠性，原因如下：
MySQL 8.0 increases the overall reliability of MySQL because :
8.0版本將元信息存儲與久經考驗的事務性存儲引擎InnoDB中。諸如用戶權限表，數據字典表，現在都使用 InnoDB進行存儲。
8.0版本消除了會導致非一致性的一處隱患。在5.7及以前的版本中，存在著服務層和引擎層兩份數據字典，因而可能導致在故障情況下的數據字典間的同步失敗。在8.0版本中，只有一份數據字典。
8.0版本實現了原子化，無懼宕機的DDL。根據這個特性，DDL語句要么被全部執行，要么全部未執行。對于復制環境來說這是至關重要的，否則會導致主從之間因為表結構不一致，數據漂移的情況。
基于新的事務型數據字典，可靠性得到了提高。
可觀測性 Observability
8.0版本重新實現了信息視圖庫，在新的實現中，信息視圖庫的表都是基于InnoDB存儲的數據字典表的簡單視圖。這比之前有了百倍的性能提升。讓信息視圖庫可以更加實用性的被外部工具引用。
8.0版本通過在性能信息庫上增加了100多個索引完成了其查詢性能的提升。這些索引是預設，且無法被刪除，修改，增加。相對于在單獨的數據結構上進行便利，其索引是通過在既存數據表上過濾掃描來實現的。不需要管理B樹，或者散列表的重建，更新及其他操作。性能信息庫的索引從行為上更像散列索引：1，可以快速返回數據，2，不支持排序操作（推到服務層處理）。根據查詢，索引會避免全表掃描的需求，而且會返回一個相當精巧的數據集。對show indexes來說，性能信息庫的索引是不可見的，但是會出現在explain的結果中和其有關的部分。
8.0版本增加了關于配置參數的有用信息，比如變量名，最大最小值，當前值的來源，更改用戶，更改時間等等。可以在一個新增的性能信息表variables_info表中進行查詢。
8.0版本使得查看服務端曝出的客戶端錯誤信息匯總統計成為可能。用戶可以在五個不同的表中查看統計信息：Global count, summary per thread, summary per user, summary per host, 和summary per account。
用戶可以查看單個錯誤信息的次數，被SQL exception句柄處理過的數量，第一次發生的時間戳，最近一次的時間戳。給予用戶適當的權限后，用戶既可以用select從中查詢，也可以使用truncate進行重置統計數據。
為了更高的觀察查詢相應時間，8.0版本在性能信息庫中提供了語句延遲的直方圖，同時會從直方圖中計算95%，99%，9999%比例的信息。這些百分比用來作為服務質量的指示器。
8.0版本在性能信息庫中增加了數據鎖生產者身份。當事務A鎖住行R時，事務B正在等待一行被A鎖住的行。新增的生產者身份將會那些數據被鎖住（本例中為行R），誰擁有鎖（本例中為事務A），誰在等待被鎖住的事務（本例中為事務B）
8.0版本為了捕獲完成的查詢樣例和此查詢案例的一些關鍵信息，針對性能信息庫中的events_statements_summary_by_digest表做了一些改動。為了捕獲一個真實的查詢，并讓用戶進行explain，并獲取查詢計劃，現增加了一列QUERY_SAMPLE_TEXT 。為了捕獲查詢樣例時間戳，增加了一列QUERY_SAMPLE_SEEN 。為了捕獲查詢執行時間，增加了一列 QUERY_SAMPLE_TIMER_WAIT 。同時FIRST_SEEN 和 LAST_SEEN 列被修改為可以使用帶小數的秒。
8.0版本在性能信息庫的 setup_instruments表上增加了諸如屬性，易變的，文檔等元信息。這些只讀信息作為生產者的在線文檔被用戶或者工具查閱。
8.0版本 帶來了對錯誤日志的重要的改革。從軟件架構的角度來說，錯誤日志成為了新的服務架構的一部分。這意味著高級用戶可以根據需要寫出自己的錯誤日志實現。雖然大多數用戶并不想這么做，但是或許會在如何寫，寫在何處上要求有些變通的空間。因此8.0版本為用戶提供了sinks和filters來實現。8.0版本實行了一個過濾服務（API），和一個默認的過濾服務實現（組件）。這里的過濾器是指抑制某些特定錯誤信息的數據和或給定錯誤信息的某部分的輸出。8.0版本實行了一個日志撰寫（API），和一個默認的日志撰寫服務實現（組件）。日志撰寫器可以接收日志信息，并將其寫入到日志中，這里的日志可以指典型的文件日志，syslog日志，或者JSON日志。
不做任何設置默認的話，8.0版本帶來了開箱即用的錯誤日志改進。比如：
錯誤編碼： 編碼格式現在為MY開頭的10000系列數據。比如： “MY-10001”。錯誤編號在GA版本中將不會變化，但是其代表的含義可能在之后的維護性版本發布中做一些改變。
系統信息：系統性的信息[System]替換了之前的 [Error]（指之前錯誤日志是系統性相關，但是前綴為[Error]的錯誤信息）,增加到錯誤日志中。
錯誤日志詳細度減弱： 默認的錯誤日志詳細信息級別log_error_verbosity 從3(輸出)改成了2（輸出警告級別及以上）
信息源部分：每個信息前面都加了[Server], [InnoDB], [Replic] 三個其中之一的注釋，以顯示信息是從哪個子系統中輸出的。
8.0GA版本錯誤日志中的啟動信息：
| 1234 | 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在需要的情況下在以后的維護性版本發布中，不改變錯誤編號的情況下改進錯誤詳細信息。同時錯誤編號還可以用于在客制化中作為過濾/屏蔽錯誤信息的實施基礎。
8.0版本將索引的可見性管理變為可能。一個不可見索引在優化器指定查詢執行計劃時不會被納入考慮。但是這個索引仍會在后臺維護，因此讓其變得可見比刪除再增加索引代價更小。設計不可見索引的目的時為了幫助DBA來判斷索引能否被刪除。如果你假設索引已經不會被用到，可以先將其設為不可見，然后觀察查詢性能，如果相關的查詢性能沒有下降的話，最后可以將其刪除。這個功能也是萬眾期盼的。
8.0版本讓用戶可以全權管理Undo表空間，比如表空間的數量，存放位置，每個undo表空間有多少回滾段。
Undo日志不在存放于系統表空間中：在版本升級的過程中，Undo日志被從系統表空間中分離出來，并放到Undo表空間中。這為現存的非獨立Undo表空間的升級留了后路。
No more Undo log in the System tablespace. Undo log is migrated out of the System tablespace and into Undo tablespaces during upgrade. This gives an upgrade path for existing 5.7 installation using the system tablespace for undo logs.
Undo表空間可以單獨管理：比如放到更快的磁盤存儲上。
Undo tablespaces can be managed separately from the System tablespace.For example, Undo tablespaces can be put on fast storage.
在線Undo表空間回收：為了Undo表空間清理的需要，生成了了兩個小的Undo表空間，這樣可以讓InnoDB在一個活躍一個清理的情況下在線收縮Undo表空間。
Reclaim space taken by unusually large transactions (online). A minimum of two Undo tablespaces are created to allow for tablespace truncation. This allows InnoDB to shrink the undo tablespace because one Undo tablespace can be active while the other is truncated.
增多回滾段，減少爭用：現在用戶可以選擇使用最多127個Undo表空間，每個表空間都有最多可達128個回滾段。更多的回滾段可以讓并行的事務更可能地為其undo日志使用獨立的回滾段，這樣可以減少對同個資源的爭用。
More rollback segments results in less contention. The user might choose to have up to 127 Undo tablespaces, each one having up to 128 rollback segments. More rollback segments mean that concurrent transactions are more likely to use separate rollback segments for their undo logs which results in less contention for the same resources.
See blog post by Kevin Lewis here.
在正常的情況下，全局的動態的參數可以在線更改，但是實例重啟后，這些沒有寫入配置文件或者與配置文件沖突的參數設定值有可能會丟失。8.0版本中可以將全局的動態參數的更改持久化。
這就讓 SET PERSIST sql_mode='STRICT_TRANS_TABLES';的寫法成為可能。這樣就可以在重啟后，參數設定值仍會留存。這個功能的使用場景很多，但是最重要的是給出了一個在更改配置文件不方便或者根本無法做到的情況下的選擇。比如某些托管的場景下，你根本沒有文件系統的訪問權限，僅有連入數據庫服務的權限。和 SET GLOBAL 相同，SET PERSIST也需要super權限。
除此之外還有 RESET PERSIST 命令，可以將之前使用SET PERSIST命令更改后參數值的持久化特性取消掉，讓這個參數值和 SET GLOBAL設置的一樣，下次啟動可能會丟失。
8.0版本也允許對大部分當前啟動環境下的只讀參數進行 SET PERSIST 更改，在下次啟動時會生效。當然了部分只讀參數是無法被設置更改的。
8.0版本增加了RESTART命令。其用途是用來允許通過SQL連接來允許遠程管理MySQL實例。比如通過 SET PERSIST 命令更改了只讀參數后，可以用這個命令來重啟MySQL實例。當然，需要shutdown權限（譯者注：同時mysqld進程需要被supervisor進程管理才可以。）。
8.0版本增加了 ALTER TABLESPACE s1 RENAME TO s2;功能，通用表空間或者共享表空間都可以被用戶創建，更改，刪除。
8.0版本支持 ALTER TABLE ... RENAME COLUMN old_name TO new_name;，這相對于現有的ALTER TABLE <table_name> CHANGE …語法（需要注明當前列所有屬性）來說是個改進。應用程序可能由于某些原因并不能獲取所該列的所有信息，因此，這是之前語法的弊端。同時之前的語法也可能會偶然導致數據丟失（rename應該是在線DDL，不需要重建表）
MySQL 8.0 implements ALTER TABLE ... RENAME COLUMN old_name TO new_name;This is an improvement over existing syntax
8.0版本將默認的驗證插件從mysql_native_password改成了caching_sha2_password。與此對應的，libmysqlclient也會采用caching_sha2_password驗證機制。新的caching_sha2_password結合了更高的安全特性（SHA2算法）和高性能（緩存）。我們目前建議所有用戶在網絡通信上使用TLS/SSL。
8.0版本正在把OpenSSL作為企業版本和社區版本的統一默認TLS/SSL庫。之前社區版本使用的是YaSSL。支持OpenSSL也是社區呼聲比較多的請求了。
8.0版本動態的和OpenSSL鏈接在一起。從MySQL軟件源的使用者角度來看，現在MySQL包依賴于系統提供的OpenSSL文件。動態的鏈接之后，OpenSSL的更新就不需要要求MySQL也一同更新或者打補丁。
8.0版本加入了對Undo和Redo日志的靜態加密。在5.7版本中，我們引入了對使用了獨立表空間的InnoDB表的加密。其可為物理的表空間數據文件提供靜態加密。在8.0版本中我們將這個貼行擴展到了Undo和Redo日志上。
8.0版本引入了SQL角色。角色是一組權限的集合。其目的是為了簡化用戶權限管理系統。可以角色賦給用戶的身上，給角色授權，創建角色，刪除角色，定義哪些角色對于當前會話是合適的。
8.0版本引入了可配置的參數 mandatory-roles，用于自動給新創建的用戶加上角色。授予給所有用戶指定的角色的權限不可以被再次分發。但是這些角色除非被設置為默認角色，否則還是需要進行激活操作。當然也可以把新引入的 activate-all-roles-on-login參數設為ON，這樣在用戶驗證通過連接進來后，所有授權角色都會自動激活。
8.0版本定義了在很多方面上一批新粒度的權限用以代替之前版本使用的SUPER權限。其本意是用于限制用戶僅獲得和自己工作相關的權限。比如 BINLOG_ADMIN, CONNECTION_ADMIN, and ROLE_ADMIN.
8.0版本引入了一個新的系統權限 XA_RECOVER_ADMIN ，用于控制執行 XA RECOVER語句的權限。所有嘗試執行 XA RECOVER 語句的非授權用戶會引起報錯。
8.0版本引入了對密碼重新使用的限制，既可以在全局層級也可以在單獨的用戶等級上配置。過往的歷史密碼由于安全的原因（會泄露密習慣，或者詞組）會被加密保存。密碼輪換策略對于其他策略來說是疊加的。可以和現有的機制（如，密碼過期和密碼安全策略等）共存。
8.0版本引入了在連續的錯誤登陸嘗試后的等待驗證過程。其設計目的用于減緩哦對用戶密碼的暴力破解。密碼連續錯誤次數和連續錯誤之后的等待時間是可以配置的。
8.0版本禁止當實例以–skip-grant-tables參數啟動時的遠程用戶連接
8.0版本在實例中引入了部分之前mysqld_safe中的邏輯。可以改善當使用 --daemonize 啟動參數時在某些情況下的可用性。這也減輕了用戶對我們即將移除的mysqld-safe腳本的依賴。
8.0 版本帶來更好的讀寫負載，IO依賴性工作負載，和業務熱數據集中的負載。另外新增的資源組特性給用戶帶來在特定硬件特定負載下將用戶線程分配給指定CPU的選項。
8.0版本對于讀寫皆有和高寫負載的拿捏恰到好處。在集中的讀寫均有的負載情況下，我們觀測到在4個用戶并發的情況下，對于高負載，和5.7版本相比有著兩倍性能的提高。在5.7上我們顯著了提高了只讀情況下的性能，8.0則顯著提高了讀寫負載的可擴展性。為MySQL提升了硬件性能的利用率，其改進是基于重新設計了InnoDB寫入Redo日志的方法。對比之前用戶線程之前互相爭搶著寫入其數據變更，在新的Redo日志解決方案中，現在Re'do日志由于其寫入和刷緩存的操作都有專用的線程來處理。用戶線程之間不在持有Redo寫入相關的鎖，整個Redo處理過程都是時間驅動。
8.0版本允許馬力全開的使用存儲設備，比如使用英特爾奧騰閃存盤的時候，我們可以在IO敏感的負載情況下獲得1百萬的采樣 QPS（這里說的IO敏感是指不在IBP中，且必須從二級存儲設備中獲取）。這個改觀是由于我們擺脫了 file_system_mutex全局鎖的爭用。
8.0版本顯著地提升了高爭用負載下的性能。高爭用負載通常發生在許多事務爭用同一行數據的鎖，導致了事務等待隊列的產生。在實際情景中，負載并不是平穩的，負載可能在特定的時間內爆發（80/20法則）。8.0版本針對短時間的爆發負載無論在每秒處理的事務數（換句話，延遲）還是95%延遲上都處理的更好。對于終端用戶來說體現在更好的硬件資源利用率（效率）上。因為系統需要盡量使用榨盡硬件性能，才可以提供更高的平均負載。
8.0版本為MySQL引入了全局資源組。有了資源組的概念后，管理人員可以管理用戶線程和系統線程對CPU的分配。這個功能可以被用來按CPU分割負載以在某些使用情景下獲取更高的效率和性能。因此DBA的工具箱中又多了一把可以幫助自己提升硬件使用率或者增加查詢性能的工具。比如在英特爾志強E7-4860 2.27GHz,40核超線程處理器上運行Sysbench讀寫負載時，我們可以通過將寫負載限制在10個核心上從而將總體請求輸入量提升一倍。資源組是相當先進的工具，但由于效果會因為負載的類型和手頭的硬件的千差萬別，這就要求經驗經驗豐富的管理人員因地制宜地進行使用。
在MySQL了團隊中，為了更可能地讓用戶體驗開箱即用，我們對MySQL的默認值保持著緊密的關注。我們已經更改了8.0版本中30多處參數為我們認為更合適的默認參數值。
8.0版本增加了關閉元數據產生并轉化成結果集的選項。構建，解析，發送，接收元數據結果集都會消耗實例，客戶端和網絡的資源。在某些場景下，元數據大小可能比實際的結果集更大，且不必要。因此在我們關閉了元數據產生和存儲后，顯著了地提升了查詢結果集的轉化。客戶端如果不想接收于數據一同傳回的元數據信息，可以設置 CLIENT_OPTIONAL_RESULTSET_METADATA
8.0版本擴展了 libmysql的C語言API，使其更加穩定地從服務器流式獲取復制事務。其設計目的在于為了實現基于binlog的程序（類似Hadoop接收MySQL數據的工具） 進而需要避免對非正式API的調用和對內部頭文件的打包
8.0版本利用多樣的的get操作和對范圍查詢的支持，提升了InnoDB的內存緩存技能。我們通過對多種get操作的支持還提升了讀性能，如用戶可以在單次內存緩存查詢中獲取多個鍵值對。對范圍查詢的支持是應臉書的Yoshinori 所請求（譯者注：MHA作者）。利用范圍查詢，用戶可以指定一個特定的范圍，并獲取此區間所有合乎需要的鍵值。這兩個特性對于減少客戶端和服務端的來回交互來說都是至關重要的。
8.0版本通過寫入redo日志，持久化了自增計數器。持久化的自增計數器解決了一個年代悠久的BUG（譯者注：實例在重啟后，自增計數器重復利用了之前被使用后刪除的自增值）。MySQL恢復進程會重放redo日志，以確保自增計數器的準確數值。不再會出現自增值計數器數值的回滾。這意味著數據庫實例在故障恢復時會將redo日志中最后一次發放的自增值作為重建計數器的起點。確保了自增計數器的值不會重復發放，計數器的數值是單調遞增的。但要注意可能會有空洞（即發放但是未使用的自增值）。未持久化的自增值在過去一直被認為是一個的有麻煩的故障點。
綜上所述，8.0版本帶來了一大堆新特性和性能提升，馬上從dev.mysql.com上下載并嘗試一下吧(￣▽￣)"。
當然你也可以從既存的5.7實例升級到8.0版本。在此過程中，你可能需要試試我們隨著shell工具包一同下發的新的升級檢查工具。這個工具可以幫你檢查既存5.7版本的8.0版本升級兼容性（譯者附：8.0.3到8.0.11不可以直接升級，或許我用到了舊的工具，改天再試）。可以試試Frédéric Descamps寫的t Migrating to MySQL 8.0 without breaking old application 博文。
在這篇文章中我們主要覆蓋了服務端的新特性。不僅如此，我們還寫了很多關于其他方面的文章，如復制，組復制，InnoDB集群，MySQL Shell,開發API及其相關的連接組件（(Connector/Node.js, Connector/Python, PHP, Connector/NET,
關于MySQL8.0 GA版本的新特性有哪些就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
