嗦一嗦 MySQL 8.0的新特性 What’s New in MySQL 8.0? (Generally Available)

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

原文作者：Geir Hoydalsvik （Oracle官方開發工程師）

翻譯：張銳志

非常高興的向大家宣佈MySQL 8.0 GA版本發佈，MySQL 8.0是一個得到全面增強且極具吸引力的新版本。不限於下面幾點：

We proudly announce General Availability of MySQL 8.0. Download now! MySQL 8.0 is an extremely exciting new version of the world’s most popular open source database with improvements across the board. Some key enhancements include:

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上閱讀源碼。

The above represents some of the highlights and I encourage you to further drill into the complete series of Milestone blog posts—8.0.0, 8.0.1, 8.0.2, 8.0.3, and 8.0.4 —and even further down in to the individual worklogs with their specifications and implementation details. Or perhaps you prefer to just look at the source code at github.com/mysql.

面向開發人員的特性 Developer features

MySQL 8.0應面向MySQL開發人員的需求，帶來了SQL，JSON，公共表達式，地理信息系統等方面的特性，因爲很多開發人員有存儲EmoJi表情的需求，在新版本中UTF8MB4成爲默認的字符集。除此之外，還有對Binary數據類型按位操作，和改進對IPV6和UUID函數的改進。

MySQL Developers want new features and MySQL 8.0 delivers many new and much requested features in areas such as SQL, JSON, Regular Expressions, and GIS. Developers also want to be able to store Emojis, thus UTF8MB4 is now the default character set in 8.0. Finally there are improvements in Datatypes, with bit-wise operations on BINARY datatypes and improved IPv6 and UUID functions.

SQL

窗口函數 Window Functions

MySQL 8.0帶來了標準SQL的窗口函數功能，窗口函數與分組聚合函數相類似的是都提供了對一組行數據的統計計算。但與分組聚合函數將多行合併成一行不同是窗口函數會在結果結果集中展現每一行的聚合。

MySQL 8.0 delivers SQL window functions. Similar to grouped aggregate functions, window functions perform some calculation on a set of rows, e.g. COUNT or SUM. But where a grouped aggregate collapses this set of rows into a single row, a window function will perform the aggregation for each row in the result set.

窗口函數有兩種使用方式，首先是常規的SQL聚合功能函數和特殊的窗口函數。常規的聚合功能函數如：COUNT,SUM等函數。而窗口函數專有的則是RANK, DENSE_RANK, PERCENT_RANK, CUME_DIST, NTILE, ROW_NUMBER, FIRST_VALUE, LAST_VALUE, NTH_VALUE, LEADand LAG等函數

Window functions come in two flavors: SQL aggregate functions used as window functions and specialized window functions. This is the set of aggregate functions in MySQL that support windowing: COUNT, SUM, AVG, MIN, MAX, BIT_OR, BIT_AND, BIT_XOR, STDDEV_POP (and its synonyms STD, STDDEV), STDDEV_SAMP, VAR_POP (and its synonym VARIANCE) and VAR_SAMP. The set of specialized window functions are: 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.

公用表達式

Common Table Expression

MySQL 8.0 帶來了支持遞歸的公用表達式的功能。非遞歸的公用表達式由於允許由form子句派生的臨時表的原因可以被多次引用，因而被解釋爲改進型的派生表（from子句中的臨時表）。而遞歸的公用表達式則由一組原始住居，經過處理後得到新的一組數據，再被帶入處理得到更多的新數據，循環往復直到再也無法產生更多新數據爲止。公用表達式也是一個用戶呼聲頻繁的SQL功能。

MySQL 8.0 delivers [Recursive] Common Table Expressions (CTEs). Non-recursive CTEs can be explained as “improved derived tables” as it allow the derived table to be referenced more than once. A recursive CTE is a set of rows which is built iteratively: from an initial set of rows, a process derives new rows, which grow the set, and those new rows are fed into the process again, producing more rows, and so on, until the process produces no more rows. CTE is a commonly requested SQL feature, see for example feature request 16244 and 32174 . See blog posts by Guilhem Bichot here, here, here, and here.

立即報錯或者跳過鎖持有的行

NOWAIT and SKIP LOCKED**

MySQL 8.0 給SQL的上鎖子句帶來了NOWAIT和SKIP LOCKED兩個額外的可選項。在原來的版本中，當行數據被UPDATE或者SELECT ... FOR UPDATE語句上鎖後，其他的事務需要等待鎖釋放才能訪問這行數據。但在某些場景下，有着要馬上獲取反饋的（不等待鎖）需求。使用NOWAIT參數後如果請求的數據中包括了被鎖住的行，將馬上會收到查詢失敗的報錯信息。使用SKIP LOCKED參數後，返回的數據將會跳過被鎖住的行。

MySQL 8.0 delivers NOWAIT and SKIP LOCKED alternatives in the SQL locking clause. Normally, when a row is locked due to an UPDATE or a SELECT ... FOR UPDATE, any other transaction will have to wait to access that locked row. In some use cases there is a need to either return immediately if a row is locked or ignore locked rows. A locking clause using NOWAIT will never wait to acquire a row lock. Instead, the query will fail with an error. A locking clause using SKIP LOCKED will never wait to acquire a row lock on the listed tables. Instead, the locked rows are skipped and not read at all. NOWAIT and SKIP LOCKED are frequently requested SQL features. See for example feature request 49763 . We also want to say thank you to Kyle Oppenheim for his code contribution! See blog post by Martin Hansson here.

降序索引

Descending Indexes**

MySQL 8.0 帶來了對降序索引的支持。在 8.0降序索引中，數據被倒序組織，正向查找。而在之前的版本中，雖然支持創建降序排列的索引，但其實現方式是通過創建常見的正序索引，然後進行反向查找來實現的。一方面來說，正序查找要比逆序查找更快，另一方面來說，真正的降序索引在複合的order by語句（即有asc又有desc）中,可以提高索引利用率，減少filesort。

MySQL 8.0 delivers support for indexes in descending order. Values in such an index are arranged in descending order, and we scan it forward. Before 8.0, when a user create a descending index, we created an ascending index and scanned it backwards. One benefit is that forward index scans are faster than backward index scans. Another benefit of a real descending index is that it enables us to use indexes instead of filesort for an ORDER BY clause with mixed ASC/DESC sort key parts. Descending Indexes is a frequently requested SQL feature. See for example feature request 13375 . See blog post by Chaithra Gopalareddy here.

分組函數 GROUPING

MySQL 8.0 帶來了GROUPING()分組函數，這個功能可以把group by子句的擴展功能（如ROLLUP）產生的過聚合的NULL值，通過0和1進行區分，1爲NULL，這樣就可以在having子句中對過聚合的無效值進行過濾。

MySQL 8.0 delivers GROUPING(), SQL_FEATURE T433. The GROUPING() function distinguishes super-aggregate rows from regular grouped rows. GROUP BY extensions such as ROLLUP produce super-aggregate rows where the set of all values is represented by null. Using the GROUPING() function, you can distinguish a null representing the set of all values in a super-aggregate row from a NULL in a regular row. GROUPING is a frequently requested SQL feature. See feature requests 3156 and 46053. Thank you to Zoe Dong and Shane Adams for code contributions in feature request 46053 ! See blog post by Chaithra Gopalareddy here.

優化器建議 Optimizer Hints

在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語義上更加清晰。

We prefer the new style of optimizer hints as preferred over the old-style hints and setting of optimizer_switch values. By not being inter-mingled with SQL, the new hints can be injected in many places in a query string. They also have clearer semantics in being a hint (vs directive).

JSON

8.0版本追加了新的JSON函數，並可以提高在排序與分組JSON數據情況下的性能。

MySQL 8.0 adds new JSON functions and improves performance for sorting and grouping JSON values.

JSON path表達式中擴展的範圍性語法 Extended Syntax for Ranges in JSON path expressions**

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.

JSON表函數 JSON Table Functions

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.

JSON 聚合函數 JSON Aggregation Functions

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 合併函數 JSON Merge Functions

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操作的不明確，而被棄用。

The existing JSON_MERGE() function is deprecated in MySQL 8.0 to remove ambiguity for the merge operation. See also proposal in Bug#81283 and blog post by Morgan Tocker here.

JSON 美化函數 JSON Pretty Function

8.0版本增加了可以接收JSON原生數據類型和字符串表達的JSON，並返回一行縮進的易讀的JSON格式化後的的字符串。

MySQL 8.0 adds a JSON_PRETTY() function in MySQL. The function accepts either a JSON native data-type or string representation of JSON and returns a JSON formatted string in a human-readable way with new lines and indentation.

JSON 文件大小函數 JSON Size Functions

8.0版本增加了和指定JSON對象空間佔用相關的函數，JSON_STORAGE_SIZE() 可以用字節爲單位返回JSON某個數據類型的實際大小， JSON_STORAGE_FREE() 可以返回該JSON數據類型的剩餘空間（包括碎片和用來適應更改後發生長度變化的預備空間）

MySQL 8.0 adds JSON functions related to space usage for a given JSON object. The JSON_STORAGE_SIZE() returns the actual size in bytes for a JSON datatype. The JSON_STORAGE_FREE() returns the free space of a JSON binary type in bytes, including fragmentation and padding saved for inplace update.

JSON 改進型的排序 JSON Improved Sorting

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.

JSON的部分更新 JSON Partial Update

8.0版本增加了對 JSON_REMOVE(), JSON_SET() and JSON_REPLACE() 函數的部分更新的支持。如果JSON文檔的某部分被更新，我們會將更改的詳情給到句柄。這樣存儲引擎和複製關係就不必寫入整個JSON文檔。在之前的複製環境中由於無法確保JSON文檔的排列(layout)在主從上完全一致，所以在基於行的複製情況下物理文件的差異並不能用來削減傳輸複製信息帶來的網絡IO消耗。因此，8.0版本提供了在邏輯上區分差異的方法，可以在行復制的情況下傳輸並應用到從庫上

MySQL 8.0 adds support for partial update for the JSON_REMOVE(), JSON_SET() and JSON_REPLACE() functions. If only some parts of a JSON document are updated, we want to give information to the handler about what was changed, so that the storage engine and replication don’t need to write the full document. In a replicated environment, it cannot be guaranteed that the layout of a JSON document is exactly the same on the slave and the master, so the physical diffs cannot be used to reduce the network I/O for row-based replication. Thus, MySQL 8.0 provides logical diffs that row-based replication can send over the wire and reapply on the slave. See blog post by Knut Anders Hatlen here.

地理信息系統 GIS

8.0 版本提供對地形的支持，其中包括了對空間參照系的數據源信息的支持，SRS aware spatial數據類型，空間索引，空間函數。總而言之，8.0版本可以理解地球表面的經緯度信息，而且可以在任意受支持的5000個空間參照系中計算地球上任意兩點之間的距離。

MySQL 8.0 delivers geography support. This includes meta-data support for Spatial Reference System (SRS), as well as SRS aware spatial datatypes, spatial indexes, and spatial functions. In short, MySQL 8.0 understands latitude and longitude coordinates on the earth’s surface and can, for example, correctly calculate the distances between two points on the earths surface in any of the about 5000 supported spatial reference systems.

空間參照系 Spatial Reference System (SRS)

ST_SPATIAL_REFERENCE_SYSTEMS 存在於information schema視圖庫中，提供了可供使用的SRS座標系統的名稱。每個SRS座標系統都有一個SRID編號。8.0版本支持EPSG Geodetic Parameter Dataseset中的5千多個座標系統（包括立體模和2D平面地球模型）

The ST_SPATIAL_REFERENCE_SYSTEMS information schema view provides information about available spatial reference systems for spatial data. This view is based on the SQL/MM (ISO/IEC 13249-3) standard. Each spatial reference system is identified by an SRID number. MySQL 8.0 ships with about 5000 SRIDs from the EPSG Geodetic Parameter Dataset, covering georeferenced ellipsoids and 2d projections (i.e. all 2D spatial reference systems).

SRID 地理數據類型 SRID aware spatial datatypes

空間類的數據類型可以直接從SRS座標系統的定義中獲取，例如：使用SRID 4326定義進行建表： CREATE TABLE t1 (g GEOMETRY SRID 4326); 。SRID是適用於地理類型的數據類型。只有同一SRID的的數據纔會被插入到行中。與當前SRID數據類型的數據嘗試插入時，會報錯。未定義SRID編號的表將可以接受所有SRID編號的數據。

Spatial datatypes can be attributed with the spatial reference system definition, for example with SRID 4326 like this: CREATE TABLE t1 (g GEOMETRY SRID 4326); The SRID is here a SQL type modifier for the GEOMETRY datatype. Values inserted into a column with an SRID property must be in that SRID. Attempts to insert values with other SRIDs results in an exception condition being raised. Unmodified types, i.e., types with no SRID specification, will continue to accept all SRIDs, as before.

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.

SRID 空間索引 SRID aware spatial indexes

在空間數據類型上可以創建空間索引，創建空間索引的列必須非空，例如： 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信息。

Columns with a spatial index should have an SRID type modifier to allow the optimizer to use the index. If a spatial index is created on a column that doesn’t have an SRID type modifier, a warning is issued.

SRID 空間函數 SRID aware spatial functions

8.0 增加了諸如 ST_Distance() 和 ST_Length() 等用於判斷數據的參數是否在SRS中，並計算其空間上的距離。到目前爲止，ST_Distance和其他的空間關係型函數諸如ST_Within,ST_Intersects,ST_Contains,ST_Crosses都支持地理計算。其運算邏輯與行爲參見 SQL/MM Part 3 Spatial

MySQL 8.0 extends spatial functions such as ST_Distance() and ST_Length() to detect that its parameters are in a geographic (ellipsoidal) SRS and to compute the distance on the ellipsoid. So far, ST_Distance and spatial relations such as ST_Within, ST_Intersects, ST_Contains, ST_Crosses, etc. support geographic computations. The behavior of each ST function is as defined in SQL/MM Part 3 Spatial.

字符集 Character Sets

8.0版本默認使用UTF8MB4作爲默認字符集。相比較5.7版本，SQL性能（諸如排序UTF8MB4字符串）得到了很大的提升。UTF8MB4類型在網頁編碼上正佔據着舉足輕重的地位，將其設爲默認數據類型後，將會給絕大多數的MySQL用戶帶來遍歷。

MySQL 8.0 makes UTF8MB4 the default character set. SQL performance – such as sorting UTF8MB4 strings – has been improved by a factor of 20 in 8.0 as compared to 5.7. UTF8MB4 is the dominating character encoding for the web, and this move will make life easier for the vast majority of MySQL users.

默認的字符集從latin1變爲 utf8mb4 ,默認排序校對規則從 latin1_swedish_ci 變爲utf8mb4_800_ci_ai。
The default character set has changed from latin1 to utf8mb4 and the default collation has changed from latin1_swedish_ci to utf8mb4_800_ci_ai.
utf8mb4同樣也成爲libmysql，服務端命令行工具,server層的默認編碼
The changes in defaults applies to libmysql and server command tools as well as the server itself.
utf8mb4同樣也成爲MySQL測試框架的默認編碼
The changes are also reflected in MTR tests, running with new default charset.
排序校對規則的權重與大小寫基於Unicode委員會16年公佈的Unicode 9.0.0版本。
The collation weight and case mapping are based on Unicode 9.0.0 , announced by the Unicode committee on Jun 21, 2016.
在以往的MySQL版本中，latin1編碼中的21種語言的特殊大小寫和排序校對規則被引入了 utf8mb4 排序校對規則。例如：捷克語的排序校對規則變成了utf8mb4_cs_800_ai_ci。
The 21 language specific case insensitive collations available for latin1 (MySQL legacy) have been implemented for utf8mb4 collations, for example the Czech collation becomes utf8mb4_cs_800_ai_ci. See complete list in WL#9108 . See blog post by Xing Zhang here .
增加了對特殊語境和重音敏感的排序校對規則的支持。8.0版本支持 DUCET (Default Unicode Collation Entry Table)全部三級排序校對規則。
Added support for case and accent sensitive collations. MySQL 8.0 supports all 3 levels of collation weight defined by DUCET (Default Unicode Collation Entry Table). See blog post by Xing Zhang here.
utf8mb4 的 utf8mb4_ja_0900_as_cs 排序校驗規則對日語字符支持三級權重的排序。
Japanese utf8mb4_ja_0900_as_cs collation for utf8mb4 which sorts characters by using three levels’ weight. This gives the correct sorting order for Japanese. See blog post by Xing Zhang here.
對日語有額外的假名支持特性， utf8mb4_ja_0900_as_cs_ks中的ks表示假名區分。
Japanese with additional kana sensitive feature, utf8mb4_ja_0900_as_cs_ks, where ‘ks’ stands for ‘kana sensitive’. See blog post by Xing Zhang here.
把 Unicode 9.0.0之前所有排序校驗規則中的不填補變成填補字符，此舉有利於提升字符串的一致性和性能。例如把字符串末尾的空格按照其他字符對待。之前的排序校驗規則在處理這種情況時保留字符串原樣。
Changed all new collations, from Unicode 9.0.0 forward, to be NO PAD instead of PAD STRING, ie., treat spaces at the end of a string like any other character. This is done to improve consistency and performance. Older collations are left in place.

See also blog posts by Bernt Marius Johnsen here, here and here.

數據類型 Datatypes

二進制數據類型的Bit-wise操作 Bit-wise operations on binary data types

8.0版本擴展了 bit-wise操作（如bit-wise AND等）的使用範圍，使得其在所有 BINARY 數據類型上都適用。在此之前只支持整型數據，若強行在二進制數據類型上使用Bit-wise操作，將會隱式轉換爲64位的BITINT類型，並可能丟失若干位的數據。從8.0版本之後，bit-wise操作可以在 BINARY 和BLOB類型上使用，且不用擔心精確度下降的問題。

MySQL 8.0 extends the bit-wise operations (‘bit-wise AND’, etc) to also work with [VAR]BINARY/[TINY|MEDIUM|LONG]BLOB. Prior to 8.0 bit-wise operations were only supported for integers. If you used bit-wise operations on binaries the arguments were implicitly cast to BIGINT (64 bit) before the operation, thus possibly losing bits. From 8.0 and onward bit-wise operations work for all BINARY and BLOB data types, casting arguments such that bits are not lost.

IPV6操作 IPV6 manipulation

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) 操作。

MySQL 8.0 improves the usability of IPv6 manipulation supporting bit-wise operations on BINARY data types. In MySQL 5.6 we introduced the INET6_ATON() and INET6_NTOA() functions which convert IPv6 addresses between text form like 'fe80::226:b9ff:fe77:eb17' and VARBINARY(16). However, until now we could not combine these IPv6 functions with bit-wise operations since such operations would – wrongly – convert output to BIGINT. For example, if we have an IPv6 address and want to test it against a network mask, we can now use INET6_ATON(address)& INET6_ATON(network) because INET6_ATON() correctly returns the VARBINARY(16)datatype (128 bits). See blog post by Catalin Besleaga here.

UUID 操作UUID manipulations

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樹中的隨機插入，從而減少了插入耗時。

MySQL 8.0 improves the usability of UUID manipulations by implementing three new SQL functions: UUID_TO_BIN(), BIN_TO_UUID(), and IS_UUID(). The first one converts from UUID formatted text to VARBINARY(16), the second one from VARBINARY(16) to UUID formatted text, and the last one checks the validity of an UUID formatted text. The UUID stored as a VARBINARY(16) can be indexed using functional indexes. The functions UUID_TO_BIN() and UUID_TO_BIN() can also shuffle the time-related bits and move them at the beginning making it index friendly and avoiding the random inserts in the B-tree, this way reducing the insert time. The lack of such functionality has been mentioned as one of the drawbacks of using UUID’s. See blog post by Catalin Besleaga here.

消耗敏感的模型 Cost Model

查詢優化器將會照顧到數據緩衝的狀況 Query Optimizer Takes Data Buffering into Account

8.0版本自動地根據數據是否存在於內存中而選擇查詢計劃，在以往的版本中，消耗敏感的模型始終假設數據在磁盤上。正因爲現在查詢內存數據和查詢硬盤數據的消耗常數不同，因此優化器會根據數據的位置選擇更加優化的讀取數據方式。

MySQL 8.0 chooses query plans based on knowledge about whether data resides in-memory or on-disk. This happens automatically, as seen from the end user there is no configuration involved. Historically, the MySQL cost model has assumed data to reside on spinning disks. The cost constants associated with looking up data in-memory and on-disk are now different, thus, the optimizer will choose more optimal access methods for the two cases, based on knowledge of the location of data. See blog post by Øystein Grøvlen here.

查詢優化器的直方圖 Optimizer Histograms

8.0版本加入了直方圖統計數據。用戶可以根據直方圖針對表中的某列（一般爲非索引列）生成數據分佈統計信息，這樣優化器就可以利用這些信息去尋覓更加優化的查詢計劃。直方圖最常見的使用場景就是計算字段的選擇性。

MySQL 8.0 implements histogram statistics. With Histograms, the user can create statistics on the data distribution for a column in a table, typically done for non-indexed columns, which then will be used by the query optimizer in finding the optimal query plan. The primary use case for histogram statistics is for calculating the selectivity (filter effect) of predicates of the form “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命令會自動的判斷是否要表進行採樣，甚至會根據表中數據的分佈情況和統計總量來決定創建等頻或者等高的直方圖。

The user creates a histogram by means of the ANALYZE TABLE syntax which has been extended to accept two new clauses: UPDATE HISTOGRAM ON column [, column] [WITH n BUCKETS] and DROP HISTOGRAM ON column [, column]. The number of buckets is optional, the default is 100. The histogram statistics are stored in the dictionary table “column_statistics” and accessible through the view information_schema.COLUMN_STATISTICS. The histogram is stored as a JSON object due to the flexibility of the JSON datatype. ANALYZE TABLE will automatically decide whether to sample the base table or not, based on table size. It will also decide whether to build a singleton or a equi-height histogram based on the data distribution and the number of buckets specified. See blog post by Erik Frøseth here.

正則表達式 Regular Expressions

與UTF8MB4的正則支持一同，8.0版本也增加了諸如 REGEXP_INSTR(), REGEXP_LIKE(), REGEXP_REPLACE(), 和REGEXP_SUBSTR()等新函數。另外，系統中還增加了用以控制正則表達式致性的 regexp_stack_limit (默認8000000比特) 和 regexp_time_limit (默認32步) 參數。REGEXP_REPLACE()也是社區中受呼聲比較高的特性。

MySQL 8.0 supports regular expressions for UTF8MB4 as well as new functions like REGEXP_INSTR(), REGEXP_LIKE(), REGEXP_REPLACE(), and REGEXP_SUBSTR(). The system variables regexp_stack_limit (default 8000000 bytes) and regexp_time_limit (default 32 steps) have been added to control the execution. The REGEXP_REPLACE() function is one of the most requested features by the MySQL community, for example see feature request reported as BUG #27389 by Hans Ginzel. See also blog posts by Martin Hansson here and Bernt Marius Johnsen here.

運維自動化特性 Dev Ops features

開發向的運維關心數據庫實例的可操作型，通常即可靠性，可用性，性能，安全，可觀測性，可管理性。關於InnoDB Cluster和MGR的可靠性我們將會另起新篇單獨介紹，接下來的段落將會介紹關於8.0版本針對表在其他可操作性上的改變。

Dev Ops care about operational aspects of the database, typically about reliability, availability, performance, security, observability, and manageability. High Availability comes with MySQL InnoDB Cluster and MySQL Group Replication which will be covered by a separate blog post. Here follows what 8.0 brings to the table in the other categories.

可靠性 Reliability

8.0版本在整體上增加了可靠性，原因如下：

MySQL 8.0 increases the overall reliability of MySQL because :

8.0版本將元信息存儲與久經考驗的事務性存儲引擎InnoDB中。諸如用戶權限表，數據字典表，現在都使用 InnoDB進行存儲。

MySQL 8.0 stores its meta-data into InnoDB, a proven transactional storage engine. System tables such as Users and Privileges as well as Data Dictionary tables now reside in InnoDB.

8.0版本消除了會導致非一致性的一處隱患。在5.7及以前的版本中，存在着服務層和引擎層兩份數據字典，因而可能導致在故障情況下的數據字典間的同步失敗。在8.0版本中，只有一份數據字典。
MySQL 8.0 eliminates one source of potential inconsistency. In 5.7 and earlier versions there are essentially two data dictionaries, one for the Server layer and one for the InnoDB layer, and these can get out of sync in some crashing scenarios. In 8.0 there is only one data dictionary.

8.0版本實現了原子化，無懼宕機的DDL。根據這個特性，DDL語句要麼被全部執行，要麼全部未執行。對於複製環境來說這是至關重要的，否則會導致主從之間因爲表結構不一致，數據漂移的情況。
MySQL 8.0 ensures atomic, crash safe DDL. With this the user is guaranteed that any DDL statement will either be executed fully or not at all. This is particularly important in a replicated environment, otherwise there can be scenarios where masters and slaves (nodes) get out of sync, causing data-drift.

基於新的事務型數據字典，可靠性得到了提高。

This work is done in the context of the new, transactional data dictionary. See blog posts by Staale Deraas here and here.

可觀測性 Observability

提高信息視圖庫的性能 Information Schema (speed up)

8.0版本重新實現了信息視圖庫，在新的實現中，信息視圖庫的表都是基於InnoDB存儲的數據字典表的簡單視圖。這比之前有了百倍的性能提升。讓信息視圖庫可以更加實用性的被外部工具引用。

MySQL 8.0 reimplements Information Schema. In the new implementation the Information Schema tables are simple views on data dictionary tables stored in InnoDB. This is by far more efficient than the old implementation with up to 100 times speedup. This makes Information Schema practically usable by external tooling. See blog posts by Gopal Shankar here and here , and the blog post by Ståle Deraas here.

提高性能信息庫的速度 Performance Schema (speed up)

8.0版本通過在性能信息庫上增加了100多個索引完成了其查詢性能的提升。這些索引是預設，且無法被刪除，修改，增加。相對於在單獨的數據結構上進行便利，其索引是通過在既存數據表上過濾掃描來實現的。不需要管理B樹，或者散列表的重建，更新及其他操作。性能信息庫的索引從行爲上更像散列索引：1，可以快速返回數據，2，不支持排序操作（推到服務層處理）。根據查詢，索引會避免全表掃描的需求，而且會返回一個相當精巧的數據集。對show indexes來說，性能信息庫的索引是不可見的，但是會出現在explain的結果中和其有關的部分。

MySQL 8.0 speeds up performance schema queries by adding more than 100 indexes on performance schema tables. The indexes on performance schema tables are predefined. They cannot be deleted,added or altered. A performance schema index is implemented as a filtered scan across the existing table data, rather than a traversal through a separate data structure. There are no B-trees or hash tables to be constructed, updated or otherwise managed. Performance Schema tables indexes behave like hash indexes in that a) they quickly retrieve the desired rows, and b) do not provide row ordering, leaving the server to sort the result set if necessary. However, depending on the query, indexes obviate the need for a full table scan and will return a considerably smaller result set. Performance schema indexes are visible with SHOW INDEXES and are represented in the EXPLAIN output for queries that reference indexed columns. See comment from Simon Mudd. See blog post by Marc Alff here.

參數配置 Configuration Variables

8.0版本增加了關於配置參數的有用信息，比如變量名，最大最小值，當前值的來源，更改用戶，更改時間等等。可以在一個新增的性能信息表variables_info表中進行查詢。

MySQL 8.0 adds useful information about configuration variables, such as the variable name, min/max values, where the current value came from, who made the change and when it was made. This information is found in a new performance schema table called variables_info. See blog post by Satish Bharathy here.

客戶端錯誤報告信息統計 Client Error Reporting – Message Counts

8.0版本使得查看服務端曝出的客戶端錯誤信息彙總統計成爲可能。用戶可以在五個不同的表中查看統計信息：Global count, summary per thread, summary per user, summary per host, 和summary per account。

用戶可以查看單個錯誤信息的次數，被SQL exception句柄處理過的數量，第一次發生的時間戳，最近一次的時間戳。給予用戶適當的權限後，用戶既可以用select從中查詢，也可以使用truncate進行重置統計數據。

MySQL 8.0 makes it possible to look at aggregated counts of client error messagesreported by the server.The user can look at statistics from 5 different tables: Global count, summary per thread, summary per user, summary per host, or summary per account. For each error message the user can see the number of errors raised, the number of errors handled by the SQL exception handler, “first seen” timestamp, and “last seen” timestamp. Given the right privileges the user can either SELECT from these tables or TRUNCATE to reset statistics. See blog post by Mayank Prasad here.

語句延遲直方圖 Statement Latency Histograms

爲了更高的觀察查詢相應時間，8.0版本在性能信息庫中提供了語句延遲的直方圖，同時會從直方圖中計算95%，99%，9999%比例的信息。這些百分比用來作爲服務質量的指示器。

MySQL 8.0 provides performance schema histograms of statements latency, for the purpose of better visibility of query response times. This work also computes “P95”, “P99” and “P999” percentiles from collected histograms. These percentiles can be used as indicators of quality of service. See blog post by Frédéric Descamps here.

圖形化數據依賴關係鎖 Data Locking Dependencies Graph

8.0版本在性能信息庫中增加了數據鎖生產者身份。當事務A鎖住行R時，事務B正在等待一行被A鎖住的行。新增的生產者身份將會那些數據被鎖住（本例中爲行R），誰擁有鎖（本例中爲事務A），誰在等待被鎖住的事務（本例中爲事務B）

MySQL 8.0 instruments data locks in the performance schema. When transaction A is locking row R, and transaction B is waiting on this very same row, B is effectively blocked by A. The added instrumentation exposes which data is locked (R), who owns the lock (A), and who is waiting for the data (B). See blog post by Frédéric Descamps here.

查詢樣例摘要 Digest Query Sample

8.0版本爲了捕獲完成的查詢樣例和此查詢案例的一些關鍵信息，針對性能信息庫中的events_statements_summary_by_digest表做了一些改動。爲了捕獲一個真實的查詢，並讓用戶進行explain，並獲取查詢計劃，現增加了一列QUERY_SAMPLE_TEXT 。爲了捕獲查詢樣例時間戳，增加了一列QUERY_SAMPLE_SEEN 。爲了捕獲查詢執行時間，增加了一列 QUERY_SAMPLE_TIMER_WAIT 。同時FIRST_SEEN 和 LAST_SEEN 列被修改爲可以使用帶小數的秒。

MySQL 8.0 makes some changes to the events_statements_summary_by_digestperformance schema table to capture a full example query and some key information about this query example. The column QUERY_SAMPLE_TEXT is added to capture a query sample so that users can run EXPLAIN on a real query and to get a query plan. The column QUERY_SAMPLE_SEEN is added to capture the query sample timestamp. The column QUERY_SAMPLE_TIMER_WAIT is added to capture the query sample execution time. The columns FIRST_SEEN and LAST_SEEN have been modified to use fractional seconds. See blog post by Frédéric Descamps here.

生產者的元信息 Meta-data about Instruments

8.0版本在性能信息庫的 setup_instruments表上增加了諸如屬性，易變的，文檔等元信息。這些只讀信息作爲生產者的在線文檔被用戶或者工具查閱。

MySQL 8.0 adds meta-data such as properties, volatility, and documentation to the performance schema table setup_instruments. This read only meta-data act as online documentation for instruments, to be looked at by users or tools. See blog post by Frédéric Descamps here.

錯誤記錄 Error Logging**

8.0版本帶來了對錯誤日誌的重要的改革。從軟件架構的角度來說，錯誤日誌成爲了新的服務架構的一部分。這意味着高級用戶可以根據需要寫出自己的錯誤日誌實現。雖然大多數用戶並不想這麼做，但是或許會在如何寫，寫在何處上要求有些變通的空間。因此8.0版本爲用戶提供了sinks和filters來實現。8.0版本實行了一個過濾服務（API），和一個默認的過濾服務實現（組件）。這裏的過濾器是指抑制某些特定錯誤信息的數據和或給定錯誤信息的某部分的輸出。8.0版本實行了一個日誌撰寫（API），和一個默認的日誌撰寫服務實現（組件）。日誌撰寫器可以接收日誌信息，並將其寫入到日誌中，這裏的日誌可以指典型的文件日誌，syslog日誌，或者JSON日誌。

MySQL 8.0 delivers a major overhaul of the MySQL error log. From a software architecture perspective the error log is made a component in the new service infrastructure. This means that advanced users can write their own error log implementation if desired. Most users will not want to write their own error log implementation but still want some flexibility in what to write and where to write it. Hence, 8.0 offers users facilities to add sinks (where) and filters (what). MySQL 8.0 implements a filtering service (API) and a default filtering service implementation (component). Filtering here means to suppress certain log messages (selection) and/or fields within a given log message (projection). MySQL 8.0 implements a log writer service (API) and a default log writer service implementation (component). Log writers accept a log event and write it to a log. This log can be a classic file, syslog, EventLog and a new JSON log writer.

不做任何設置默認的話，8.0版本帶來了開箱即用的錯誤日誌改進。比如：

By default, without any configuration, MySQL 8.0 delivers many out-of-the-box error log improvements such as:

錯誤編碼： 編碼格式現在爲MY開頭的10000系列數據。比如： “MY-10001”。錯誤編號在GA版本中將不會變化，但是其代表的含義可能在之後的維護性版本發佈中做一些改變。
Error numbering: The format is a number in the 10000 series preceded by “MY-“, for example “MY-10001”. Error numbers will be stable in a GA release, but the corresponding error texts are allowed to change (i.e. improve) in maintenance releases.
系統信息：系統性的信息[System]替換了之前的 [Error]（指之前錯誤日誌是系統性相關，但是前綴爲[Error]的錯誤信息）,增加到錯誤日誌中。
System messages: System messages are written to the error log as [System] instead of [Error], [Warning], [Note]. [System] and [Error] messages are printed regardless of verbosity and cannot be suppressed. [System] messages are only used in a few places, mainly associated with major state transitions such as starting or stopping the server.
錯誤日誌詳細度減弱： 默認的錯誤日誌詳細信息級別log_error_verbosity 從3(輸出)改成了2（輸出警告級別及以上）
Reduced verbosity: The default of log_error_verbosity changes from 3 (Notes) to 2 (Warning). This makes MySQL 8.0 error log less verbose by default.
信息源部分：每個信息前面都加了[Server], [InnoDB], [Replic] 三個其中之一的註釋，以顯示信息是從哪個子系統中輸出的。
Source Component: Each message is annotated with one of three values [Server], [InnoDB], [Replic] showing which sub-system the message is coming from.

8.0GA版本錯誤日誌中的啓動信息：

This is what is written to the error log in 8.0 GA after startup :

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在需要的情況下在以後的維護性版本發佈中，不改變錯誤編號的情況下改進錯誤詳細信息。同時錯誤編號還可以用於在客製化中作爲過濾/屏蔽錯誤信息的實施基礎。

The introduction of error numbering in the error log allows MySQL to improve an error text in upcoming maintenance releases (if needed) while keeping the error number (ID) unchanged. Error numbers also act as the basis for filtering/suppression and internationalization/localization.

可管理性 Manageability

不可見索引 INVISIBLE Indexes

8.0版本將索引的可見性管理變爲可能。一個不可見索引在優化器指定查詢執行計劃時不會被納入考慮。但是這個索引仍會在後臺維護，因此讓其變得可見比刪除再增加索引代價更小。設計不可見索引的目的時爲了幫助DBA來判斷索引能否被刪除。如果你假設索引已經不會被用到，可以先將其設爲不可見，然後觀察查詢性能，如果相關的查詢性能沒有下降的話，最後可以將其刪除。這個功能也是萬衆期盼的。

MySQL 8.0 adds the capability of toggling the visibility of an index (visible/invisible). An invisible index is not considered by the optimizer when it makes the query execution plan. However, the index is still maintained in the background so it is cheap to make it visible again. The purpose of this is for a DBA / DevOp to determine whether an index can be dropped or not. If you suspect an index of not being used you first make it invisible, then monitor query performance, and finally remove the index if no query slow down is experienced. This feature has been asked for by many users, for example through Bug#70299. See blog post by Martin Hansson here.

靈活的Undo表空間管理 Flexible Undo Tablespace Management

8.0版本讓用戶可以全權管理Undo表空間，比如表空間的數量，存放位置，每個undo表空間有多少回滾段。

MySQL 8.0 gives the user full control over Undo tablespaces, i.e. how manytablespaces, where are they placed, and how many rollback segments in each.

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.

將全局參數設置持久化 SET PERSIST for global variables

在正常的情況下，全局的動態的參數可以在線更改，但是實例重啓後，這些沒有寫入配置文件或者與配置文件衝突的參數設定值有可能會丟失。8.0版本中可以將全局的動態參數的更改持久化。

MySQL 8.0 makes it possible to persist global, dynamic server variables. Many server variables are both GLOBAL and DYNAMIC and can be reconfigured while the server is running. For example: SET GLOBAL sql_mode='STRICT_TRANS_TABLES';However, such settings are lost upon a server restart.

這就讓 SET PERSIST sql_mode='STRICT_TRANS_TABLES';的寫法成爲可能。這樣就可以在重啓後，參數設定值仍會留存。這個功能的使用場景很多，但是最重要的是給出了一個在更改配置文件不方便或者根本無法做到的情況下的選擇。比如某些託管的場景下，你根本沒有文件系統的訪問權限，僅有連入數據庫服務的權限。和 SET GLOBAL 相同，SET PERSIST也需要super權限。

This work makes it possible to write SET PERSIST sql_mode='STRICT_TRANS_TABLES';The effect is that the setting will survive a server restart. There are many usage scenarios for this functionality but most importantly it gives a way to manage server settings when editing the configuration files is inconvenient or not an option. For example in some hosted environments you don’t have file system access, all that you have is the ability to connect to one or more servers. As for SET GLOBAL you need the super privilege for SET PERSIST.

除此之外還有 RESET PERSIST 命令，可以將之前使用SET PERSIST命令更改後參數值的持久化特性取消掉，讓這個參數值和 SET GLOBAL設置的一樣，下次啓動可能會丟失。

There is also the RESET PERSIST command. The RESET PERSIST command has the semantic of removing the configuration variable from the persist configuration, thus converting it to have similar behavior as SET GLOBAL.

8.0版本也允許對大部分當前啓動環境下的只讀參數進行 SET PERSIST 更改，在下次啓動時會生效。當然了部分只讀參數是無法被設置更改的。

MySQL 8.0 allows SET PERSIST to set most read-only variables as well, the new values will here take effect at the next server restart. Note that a small subset of read-only variables are left intentionally not settable. See blog post by Satish Bharathy here.

遠程管理 Remote Management

8.0版本增加了RESTART命令。其用途是用來允許通過SQL連接來允許遠程管理MySQL實例。比如通過 SET PERSIST 命令更改了只讀參數後，可以用這個命令來重啓MySQL實例。當然，需要shutdown權限（譯者注：同時mysqld進程需要被supervisor進程管理纔可以。）。

MySQL 8.0 implements an SQL RESTART command. The purpose is to enable remote management of a MySQL server over an SQL connection, for example to set a non-dynamic configuration variable by SET PERSIST followed by a RESTART. See blog post MySQL 8.0: changing configuration easily and cloud friendly ! by Frédéric Descamps.

重命名錶空間 Rename Tablespace (SQL DDL)

8.0版本增加了 ALTER TABLESPACE s1 RENAME TO s2;功能，通用表空間或者共享表空間都可以被用戶創建，更改，刪除。

MySQL 8.0 implements ALTER TABLESPACE s1 RENAME TO s2; A shared/general tablespace is a user-visible entity which users can CREATE, ALTER, and DROP. See also Bug#26949, Bug#32497, and Bug#58006.

列重命名 Rename Column (SQL DDL)

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 ALTER TABLE <table_name> CHANGE … which requires re-specification of all the attributes of the column. The old/existing syntax has the disadvantage that all the column information might not be available to the application trying to do the rename. There is also a risk of accidental data type change in the old/existing syntax which might result in data loss.

安全特性 Security features

新的默認驗證插件 New Default Authentication Plugin

8.0版本將默認的驗證插件從mysql_native_password改成了caching_sha2_password。與此對應的，libmysqlclient也會採用caching_sha2_password驗證機制。新的caching_sha2_password結合了更高的安全特性（SHA2算法）和高性能（緩存）。我們目前建議所有用戶在網絡通信上使用TLS/SSL。

MySQL 8.0 changes the default authentication plugin from mysql_native_passwordto caching_sha2_password. Correspondingly, libmysqlclient will use caching_sha2_password as the default authentication mechanism, too. The new caching_sha2_password combines better security (SHA2 algorithm) with high performance (caching). The general direction is that we recommend all users to use TLS/SSL for all their network communication. See blog post by Harin Vadodaria here.

社區版本默認使用OpenSSL OpenSSL by Default in Community Edition

8.0版本正在把OpenSSL作爲企業版本和社區版本的統一默認TLS/SSL庫。之前社區版本使用的是YaSSL。支持OpenSSL也是社區呼聲比較多的請求了。

MySQL 8.0 is unifying on OpenSSL as the default TLS/SSL library for both MySQL Enterprise Edition and MySQL Community Edition. Previously, MySQL Community Edition used YaSSL. Supporting OpenSSL in the MySQL Community Edition has been one of the most frequently requested features. See blog post by Frédéric Descamps here.

動態鏈接的OpenSSL OpenSSL is Dynamically Linked

8.0版本動態的和OpenSSL鏈接在一起。從MySQL軟件源的使用者角度來看，現在MySQL包依賴於系統提供的OpenSSL文件。動態的鏈接之後，OpenSSL的更新就不需要要求MySQL也一同更新或者打補丁。

MySQL 8.0 is linked dynamically with OpenSSL. Seen from the MySQL Repositoryusers perspective , the MySQL packages depends on the OpenSSL files provided by the Linux system at hand. By dynamically linking, OpenSSL updates can be applied upon availability without requiring a MySQL upgrade or patch. See blog post by Frédéric Descamps here.

對Undo和Redo日誌的加密 Encryption of Undo and Redo log

8.0版本加入了對Undo和Redo日誌的靜態加密。在5.7版本中，我們引入了對使用了獨立表空間的InnoDB表的加密。其可爲物理的表空間數據文件提供靜態加密。在8.0版本中我們將這個貼行擴展到了Undo和Redo日誌上。

MySQL 8.0 implements data-at-rest encryption of UNDO and REDO logs. In 5.7 we introduced Tablespace Encryption for InnoDB tables stored in file-per-table tablespaces. This feature provides at-rest encryption for physical tablespace data files. In 8.0 we extend this to include UNDO and REDO logs. See documentation here.

SQL 角色SQL roles

8.0版本引入了SQL角色。角色是一組權限的集合。其目的是爲了簡化用戶權限管理系統。可以角色賦給用戶的身上，給角色授權，創建角色，刪除角色，定義哪些角色對於當前會話是合適的。

MySQL 8.0 implements SQL Roles. A role is a named collection of privileges. The purpose is to simplify the user access right management. One can grant roles to users, grant privileges to roles, create roles, drop roles, and decide what roles are applicable during a session. See blog post by Frédéric Descamps here.

允許爲公用角色授權或收回權限 Allow grants and revokes for PUBLIC

8.0版本引入了可配置的參數 mandatory-roles，用於自動給新創建的用戶加上角色。授予給所有用戶指定的角色的權限不可以被再次分發。但是這些角色除非被設置爲默認角色，否則還是需要進行激活操作。當然也可以把新引入的 activate-all-roles-on-login參數設爲ON，這樣在用戶驗證通過連接進來後，所有授權角色都會自動激活。

MySQL 8.0 introduces the configuration variable mandatory-roles which can be used for automatic assignment and granting of default roles when new users are created. Example: role1@%,role2,role3,role4@localhost. All the specified roles are always considered granted to every user and they can’t be revoked. These roles still require activation unless they are made into default roles. When the new server configuration variable activate-all-roles-on-login is set to “ON”, all granted roles are always activated after the user has authenticated.

分解super權限 Breaking up the super privileges

8.0版本定義了在很多方面上一批新粒度的權限用以代替之前版本使用的SUPER權限。其本意是用於限制用戶僅獲得和自己工作相關的權限。比如 BINLOG_ADMIN, CONNECTION_ADMIN, and ROLE_ADMIN.

MySQL 8.0 defines a set of new granular privileges for various aspects of what SUPER is used for in previous releases. The purpose is to limit user access rights to what is needed for the job at hand and nothing more. For example BINLOG_ADMIN, CONNECTION_ADMIN, and ROLE_ADMIN.

用於管理XA事務的授權模型 Authorization model to manage XA-transactions

8.0版本引入了一個新的系統權限 XA_RECOVER_ADMIN ，用於控制執行 XA RECOVER語句的權限。所有嘗試執行 XA RECOVER 語句的非授權用戶會引起報錯。

MySQL 8.0 introduces a new system privilege XA_RECOVER_ADMIN which controls the capability to execute the statement XA RECOVER. An attempt to do XA RECOVER by a user who wasn’t granted the new system privilege XA_RECOVER_ADMIN will cause an error.

密碼輪換策略 Password rotation policy

8.0版本引入了對密碼重新使用的限制，既可以在全局層級也可以在單獨的用戶等級上配置。過往的歷史密碼由於安全的原因（會泄露密習慣，或者詞組）會被加密保存。密碼輪換策略對於其他策略來說是疊加的。可以和現有的機制（如，密碼過期和密碼安全策略等）共存。

MySQL 8.0 introduces restrictions on password reuse. Restrictions can be configured at global level as well as individual user level. Password history is kept secure because it may give clues about habits or patterns used by individual users when they change their password. The password rotation policy comes in addition to other, existing mechanisms such as the password expiration policy and allowed password policy. See Password Management.

減緩對用戶密碼的暴力破解 Slow down brute force attacks on user passwords

8.0版本引入了在連續的錯誤登陸嘗試後的等待驗證過程。其設計目的用於減緩哦對用戶密碼的暴力破解。密碼連續錯誤次數和連續錯誤之後的等待時間是可以配置的。

MySQL 8.0 introduces a delay in the authentication process based on consecutive unsuccessful login attempts. The purpose is to slow down brute force attacks on user passwords. It is possible to configure the number of consecutive unsuccessful attempts before the delay is introduced and the maximum amount of delay introduced.

撤銷skip-grant-tables（指遠程連接情況下） Retire skip-grant-tables

8.0版本禁止當實例以–skip-grant-tables參數啓動時的遠程用戶連接

MySQL 8.0 disallows remote connections when the server is started with –skip-grant-tables. See also Bug#79027 reported by Omar Bourja.

爲實例增加mysqld_safe的部分功能 Add mysqld_safe-functionality to server

8.0版本在實例中引入了部分之前mysqld_safe中的邏輯。可以改善當使用 --daemonize 啓動參數時在某些情況下的可用性。這也減輕了用戶對我們即將移除的mysqld-safe腳本的依賴。

MySQL 8.0 implement parts of the logic currently found in the mysqld_safe script inside the server. The work improves server usability in some scenarios for example when using the --daemonize startup option. The work also make users less dependent upon the mysqld_safe script, which we hope to remove in the future. It also fixes Bug#75343 reported by Peter Laursen.

性能 Performance

8.0 版本帶來更好的讀寫負載，IO依賴性工作負載，和業務熱數據集中的負載。另外新增的資源組特性給用戶帶來在特定硬件特定負載下將用戶線程分配給指定CPU的選項。

MySQL 8.0 comes with better performance for Read/Write workloads, IO bound workloads, and high contention “hot spot” workloads. In addition, the new Resource Group feature gives users an option to optimize for specific workloads on specific hardware by mapping user threads to CPUs.

可伸縮的讀寫負載 Scaling Read/Write Workloads

8.0版本對於讀寫皆有和高寫負載的拿捏恰到好處。在集中的讀寫均有的負載情況下，我們觀測到在4個用戶併發的情況下，對於高負載，和5.7版本相比有着兩倍性能的提高。在5.7上我們顯著了提高了只讀情況下的性能，8.0則顯著提高了讀寫負載的可擴展性。爲MySQL提升了硬件性能的利用率，其改進是基於重新設計了InnoDB寫入Redo日誌的方法。對比之前用戶線程之前互相爭搶着寫入其數據變更，在新的Redo日誌解決方案中，現在Re'do日誌由於其寫入和刷緩存的操作都有專用的線程來處理。用戶線程之間不在持有Redo寫入相關的鎖，整個Redo處理過程都是時間驅動。。

MySQL 8.0 scales well on RW and heavy write workloads. On intensive RW workloads we observe better performance already from 4 concurrent users and more than 2 times better performance on high loads comparing to MySQL 5.7. We can say that while 5.7 significantly improved scalability for Read Only workloads, 8.0 significantly improves scalability for Read/Write workloads. The effect is that MySQL improves hardware utilization (efficiency) for standard server side hardware (like systems with 2 CPU sockets). This improvement is due to re-designing how InnoDB writes to the REDO log. In contrast to the historical implementation where user threads were constantly fighting to log their data changes, in the new REDO log solution user threads are now lock-free, REDO writing and flushing is managed by dedicated background threads, and the whole REDO processing becomes event-driven. See blog post by Dimitri Kravtchuk here.

榨乾IO能力（在更快速的存儲設備上） Utilizing IO Capacity (Fast Storage)**

8.0版本允許馬力全開的使用存儲設備，比如使用英特爾奧騰閃存盤的時候，我們可以在IO敏感的負載情況下獲得1百萬的採樣 QPS（這裏說的IO敏感是指不在IBP中，且必須從二級存儲設備中獲取）。這個改觀是由於我們擺脫了 file_system_mutex全局鎖的爭用。

MySQL 8.0 allows users to use every storage device to its full power. For example, testing with Intel Optane flash devices we were able to out-pass 1M Point-Select QPS in a fully IO-bound workload. (IO bound means that data are not cached in buffer pool but must be retrieved from secondary storage). This improvement is due to getting rid of the fil_system_mutex global lock.

在高爭用（熱點數據）負載情況下的更優性能 Better Performance upon High Contention Loads (“hot rows”)

8.0版本顯著地提升了高爭用負載下的性能。高爭用負載通常發生在許多事務爭用同一行數據的鎖，導致了事務等待隊列的產生。在實際情景中，負載並不是平穩的，負載可能在特定的時間內爆發（80/20法則）。8.0版本針對短時間的爆發負載無論在每秒處理的事務數（換句話，延遲）還是95%延遲上都處理的更好。對於終端用戶來說體現在更好的硬件資源利用率（效率）上。因爲系統需要儘量使用榨盡硬件性能，纔可以提供更高的平均負載。

MySQL 8.0 significantly improves the performance for high contention workloads. A high contention workload occurs when multiple transactions are waiting for a lock on the same row in a table, causing queues of waiting transactions. Many real world workloads are not smooth over for example a day but might have bursts at certain hours (Pareto distributed). MySQL 8.0 deals much better with such bursts both in terms of transactions per second, mean latency, and 95th percentile latency. The benefit to the end user is better hardware utilization (efficiency) because the system needs less spare capacity and can thus run with a higher average load. The original patch was contributed by Jiamin Huang (Bug#84266). Please study the Contention-Aware Transaction Scheduling (CATS) algorithm and read the MySQL blog post by Jiamin Huang and Sunny Bains here.

資源組 Resource Groups

8.0版本爲MySQL引入了全局資源組。有了資源組的概念後，管理人員可以管理用戶線程和系統線程對CPU的分配。這個功能可以被用來按CPU分割負載以在某些使用情景下獲取更高的效率和性能。因此DBA的工具箱中又多了一把可以幫助自己提升硬件使用率或者增加查詢性能的工具。比如在英特爾志強E7-4860 2.27GHz,40核超線程處理器上運行Sysbench讀寫負載時，我們可以通過將寫負載限制在10個核心上從而將總體請求輸入量提升一倍。資源組是相當先進的工具，但由於效果會因爲負載的類型和手頭的硬件的千差萬別，這就要求經驗經驗豐富的管理人員因地制宜地進行使用。

MySQL 8.0 introduces global Resource Groups to MySQL. With Resource Groups, DevOps/DBAs can manage the mapping between user/system threads and CPUs. This can be used to split workloads across CPUs to obtain better efficiency and/or performance in some use cases. Thus, Resource Groups adds a tool to the DBA toolbox, a tool which can help the DBA to increase hardware utilization or to increase query stability. As an example, with a Sysbench RW workload running on a Intel(R) Xeon (R) CPU E7-4860 2.27 GHz 40 cores-HT box we doubled the overall throughput by limiting the Write load to 10 cores. Resource Groups is a fairly advanced tool which requires skilled DevOps/DBA to be used effectively as effects will vary with type of load and with the hardware at hand.

其他特性 Other Features

更優的默認值 Better Defaults

在MySQL了團隊中，爲了更可能地讓用戶體驗開箱即用，我們對MySQL的默認值保持着緊密的關注。我們已經更改了8.0版本中30多處參數爲我們認爲更合適的默認參數值。

In the MySQL team we pay close attention to the default configuration of MySQL, and aim for users to have the best out of the box experience possible. MySQL 8.0 has changed more than 30 default values to what we think are better values. See blog post New Defaults in MySQL 8.0. The motivation for this is outlined in a blog post by Mogan Tocker here.

協議 Protocol

8.0版本增加了關閉元數據產生並轉化成結果集的選項。構建，解析，發送，接收元數據結果集都會消耗實例，客戶端和網絡的資源。在某些場景下，元數據大小可能比實際的結果集更大，且不必要。因此在我們關閉了元數據產生和存儲後，顯著了地提升了查詢結果集的轉化。客戶端如果不想接收於數據一同傳回的元數據信息，可以設置 CLIENT_OPTIONAL_RESULTSET_METADATA

MySQL 8.0 adds an option to turn off metadata generation and transfer for resultsets. Constructing/parsing and sending/receiving resultset metadata consumes server, client and network resources. In some cases the metadata size can be much bigger than actual result data size and the metadata is just not needed. We can significantly speed up the query result transfer by completely disabling the generation and storage of these data. Clients can set the CLIENT_OPTIONAL_RESULTSET_METADATA flag if they do not want meta-data back with the resultset.

C語言客戶端 API C Client API

8.0版本擴展了 libmysql的C語言API，使其更加穩定地從服務器流式獲取複製事務。其設計目的在於爲了實現基於binlog的程序（類似Hadoop接收MySQL數據的工具）進而需要避免對非正式API的調用和對內部頭文件的打包

MySQL 8.0 extends libmysql’s C API with a stable interface for getting replication events from the server as a stream of packets. The purpose is to avoid having to call undocumented APIs and package internal header files in order to implement binlog based programs like the MySQL Applier for Hadoop.

內存緩存 Memcached

8.0版本利用多樣的的get操作和對範圍查詢的支持，提升了InnoDB的內存緩存技能。我們通過對多種get操作的支持還提升了讀性能，如用戶可以在單次內存緩存查詢中獲取多個鍵值對。對範圍查詢的支持是應臉書的Yoshinori 所請求（譯者注：MHA作者）。利用範圍查詢，用戶可以指定一個特定的範圍，並獲取此區間所有合乎需要的鍵值。這兩個特性對於減少客戶端和服務端的來回交互來說都是至關重要的。

MySQL 8.0 enhances the InnoDB Memcached functionalities with multiple getoperations and support for range queries. We added support for the multiple getoperation to further improve the read performance, i.e. the user can fetch multiple key value pairs in a single memcached query. Support for range queries has been requested by Yoshinori @ Facebook. With range queries, the user can specify a particular range, and fetch all the qualified values in this range. Both features can significantly reduce the number of roundtrips between the client and the server.

持久化的自增計數器 Persistent Autoinc Counters

8.0版本通過寫入redo日誌，持久化了自增計數器。持久化的自增計數器解決了一個年代悠久的BUG（譯者注：實例在重啓後，自增計數器重複利用了之前被使用後刪除的自增值）。MySQL恢復進程會重放redo日誌，以確保自增計數器的準確數值。不再會出現自增值計數器數值的回滾。這意味着數據庫實例在故障恢復時會將redo日誌中最後一次發放的自增值作爲重建計數器的起點。確保了自增計數器的值不會重複發放，計數器的數值是單調遞增的。但要注意可能會有空洞（即發放但是未使用的自增值）。未持久化的自增值在過去一直被認爲是一個的有麻煩的故障點。

MySQL 8.0 persists the AUTOINC counters by writing them to the redo log. This is a fix for the very old Bug#199. The MySQL recovery process will replay the redo log and ensure correct values of the AUTOINC counters. There won’t be any rollback of AUTOINCcounters. This means that database recovery will reestablish the last known counter value after a crash. It comes with the guarantee that the AUTOINC counter cannot get the same value twice. The counter is monotonically increasing, but note that there can be gaps (unused values). The lack of persistent AUTOINC has been seen as troublesome in the past, e.g. see Bug#21641 reported by Stephen Dewey in 2006 or this blog post .

總結 Summary

綜上所述，8.0版本帶來了一大堆新特性和性能提升，馬上從dev.mysql.com上下載並嘗試一下吧(￣▽￣)"。

As shown above, MySQL 8.0 comes with a large set of new features and performance improvements. Download it from dev.mysql.com and try it out !

當然你也可以從既存的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 博文。

You can also upgrade an existing MySQL 5.7 to MySQL 8.0. In the process you might want to try our new Upgrade Checker that comes with the new MySQL Shell (mysqlsh). This utility will analyze your existing 5.7 server and tell you about potential 8.0 incompatibilities. Another good resource is the blog post Migrating to MySQL 8.0 without breaking old application by Frédéric Descamps.

在這篇文章中我們主要覆蓋了服務端的新特性。不僅如此，我們還寫了很多關於其他方面的文章，如複製，組複製，InnoDB集羣，MySQL Shell,開發API及其相關的連接組件（(Connector/Node.js, Connector/Python, PHP, Connector/NET, Connector/ODBC,Connector/C++, and Connector/J）

In this blog post we have covered Server features. There is much more! We will also publish blog posts for other features such as Replication, Group Replication, InnoDB Cluster, Document Store, MySQL Shell, DevAPI, and DevAPI based Connectors (Connector/Node.js, Connector/Python, PHP, Connector/NET, Connector/ODBC,Connector/C++, and Connector/J).

就這麼多，感謝您使用MySQL

That’s it for now, and thank you for using MySQL !

注：拖拖拉拉一週終於翻譯完，困得要命，手頭有其他的事情，暫時沒時間精力進行復核，請各位見諒。文章分享在github和blog上，大家可以提request，留言，或者通過QQ微信等工具共同交流，共同學習。

【MySQL】【翻譯】8.0 GA版本的新特性 What’s New in MySQL 8.0