MySQL8.0 GA版本的新特性有哪些

這篇文章將為大家詳細(xì)講解有關(guān)MySQL8.0 GA版本的新特性有哪些，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

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

非常高興的向大家宣布MySQL 8.0 GA版本發(fā)布，MySQL 8.0是一個(gè)得到全面增強(qiáng)且極具吸引力的新版本。不限于下面幾點(diǎn)：

SQL方面：窗口函數(shù)，公共表達(dá)式，NOWAIT,SKIPLOCKED,降序索引，分組，正則表達(dá)式，字符集，基于性能損耗的優(yōu)化模式，直方圖

1. SQL Window functions, Common Table Expressions, NOWAIT and SKIP LOCKED, Descending Indexes, Grouping, Regular Expressions, Character Sets, Cost Model, and Histograms.

   對(duì)JSON的支持：擴(kuò)充語法，新功能，增強(qiáng)排序，部分更新性能，基于JSON表的特性，可以使用SQL處理工具處理JSON數(shù)據(jù)。

2. JSON Extended syntax, new functions, improved sorting, and partial updates. With JSON table functions you can use the SQL machinery for JSON data.

   對(duì)地理信息系統(tǒng)的支持

3. GIS Geography support. Spatial Reference Systems (SRS), as well as SRS aware spatial datatypes,  spatial indexes,  and spatial functions.

   可靠性：DDL語句現(xiàn)在實(shí)現(xiàn)原子性和故障恢復(fù)（元信息數(shù)據(jù)被存在了一個(gè)基于InnoDB的單獨(dú)事務(wù)性數(shù)據(jù)字典中）。

4. Reliability DDL statements have become atomic and crash safe, meta-data is stored in a single, transactional data dictionary. Powered by InnoDB!

   可觀察性：對(duì)P_S,I_S,配置參數(shù)，錯(cuò)誤日志的記錄有了極其重要的增強(qiáng)

5. Observability Significant enhancements to Performance Schema, Information Schema, Configuration Variables, and Error Logging.

   可管理性：遠(yuǎn)程管理，Undo表空間管理，快速DDL

6. Manageability Remote management, Undo tablespace management, and new instant DDL.

   安全性：OpenSSL的改進(jìn)，新的默認(rèn)驗(yàn)證方式，SQL角色權(quán)限，分解super權(quán)限，密碼強(qiáng)度等等

7. Security OpenSSL improvements, new default authentication, SQL Roles, breaking up the super privilege, password strength, and more.

   性能：InnoDB在讀寫，帶寬限制，業(yè)務(wù)熱數(shù)據(jù)集中的場(chǎng)景上上有著舉足輕重的優(yōu)點(diǎn)，新增的資源組特性額外給用戶一個(gè)在特定負(fù)載和特定硬件情況下將用戶線程映射到指定的CPU上的調(diào)節(jié)選項(xiàng)

8. 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版本的部分亮點(diǎn)，我（原文作者）推薦您仔細(xì)閱讀GA版本前幾個(gè)版本的發(fā)布信息，甚至這些特性和實(shí)現(xiàn)方法的的項(xiàng)目日志?；蛘吣梢赃x擇直接在Github上閱讀源碼。

面向開發(fā)人員的特性  Developer features

MySQL 8.0應(yīng)面向MySQL開發(fā)人員的需求，帶來了SQL，JSON，公共表達(dá)式，地理信息系統(tǒng)等方面的特性，因?yàn)楹芏嚅_發(fā)人員有存儲(chǔ)EmoJi表情的需求，在新版本中UTF8MB4成為默認(rèn)的字符集。除此之外，還有對(duì)Binary數(shù)據(jù)類型按位操作，和改進(jìn)對(duì)IPV6和UUID函數(shù)的改進(jìn)。

SQL

MySQL 8.0帶來了標(biāo)準(zhǔn)SQL的窗口函數(shù)功能，窗口函數(shù)與分組聚合函數(shù)相類似的是都提供了對(duì)一組行數(shù)據(jù)的統(tǒng)計(jì)計(jì)算。但與分組聚合函數(shù)將多行合并成一行不同是窗口函數(shù)會(huì)在結(jié)果結(jié)果集中展現(xiàn)每一行的聚合。

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

對(duì)窗口函數(shù)的支持上，是用戶呼聲比較頻繁。窗口函數(shù)早在SQL2003規(guī)范中就成為了標(biāo)準(zhǔn)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 帶來了支持遞歸的公用表達(dá)式的功能。非遞歸的公用表達(dá)式由于允許由form子句派生的臨時(shí)表的原因可以被多次引用，因而被解釋為改進(jìn)型的派生表（from子句中的臨時(shí)表）。而遞歸的公用表達(dá)式則由一組原始住居，經(jīng)過處理后得到新的一組數(shù)據(jù)，再被帶入處理得到更多的新數(shù)據(jù)，循環(huán)往復(fù)直到再也無法產(chǎn)生更多新數(shù)據(jù)為止。公用表達(dá)式也是一個(gè)用戶呼聲頻繁的SQL功能。

MySQL 8.0 給SQL的上鎖子句帶來了NOWAIT和SKIP LOCKED兩個(gè)額外的可選項(xiàng)。在原來的版本中，當(dāng)行數(shù)據(jù)被UPDATE或者SELECT ... FOR UPDATE語句上鎖后，其他的事務(wù)需要等待鎖釋放才能訪問這行數(shù)據(jù)。但在某些場(chǎng)景下，有著要馬上獲取反饋的（不等待鎖）需求。使用NOWAIT參數(shù)后如果請(qǐng)求的數(shù)據(jù)中包括了被鎖住的行，將馬上會(huì)收到查詢失敗的報(bào)錯(cuò)信息。使用SKIP LOCKED參數(shù)后，返回的數(shù)據(jù)將會(huì)跳過被鎖住的行。

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

MySQL 8.0 帶來了GROUPING()分組函數(shù)，這個(gè)功能可以把group by子句的擴(kuò)展功能（如ROLLUP）產(chǎn)生的過聚合的NULL值，通過0和1進(jìn)行區(qū)分，1為NULL，這樣就可以在having子句中對(duì)過聚合的無效值進(jìn)行過濾。

在5.7版本中我們引入了新的優(yōu)化器建議的語法，借助這個(gè)新的語法，優(yōu)化器建議可以被用/*+ */包裹起來直接放在SELECT | INSERT | REPLACE | UPDATE | DELETE關(guān)鍵字的后面。在8.0的版本中我們又加入了新的姿勢(shì)。

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,允許用戶在單個(gè)查詢中控制是否使用索引合并特性。

• 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表關(guān)聯(lián)的順序。

• 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，該優(yōu)化器建議可以設(shè)定一個(gè)只在下一條語句中生效的的系統(tǒng)參數(shù)。

• 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.

相對(duì)于之前的優(yōu)化器建議和優(yōu)化器特性開關(guān)參數(shù)，我們更傾向于推薦新形式的優(yōu)化器建議，新形式的優(yōu)化器建議可以在不侵入SQL語句（指修改語句的非注釋的業(yè)務(wù)部分）的情況下，注入查詢語句的很多位置。與直接修改語句的優(yōu)化器建議相比，新形勢(shì)的優(yōu)化器建議在SQL語義上更加清晰。

JSON

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

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

MySQL 8.0 擴(kuò)展了JSON path表達(dá)式中范圍性的語法，比如：SELECT JSON_EXTRACT('[1, 2, 3, 4, 5]', '$[1 to 3]');可以得出[2, 3, 4]的結(jié)果

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數(shù)據(jù)上使用SQL處理工具的JSON 表函數(shù)。JSON_TABLE()函數(shù)可以創(chuàng)建JSON數(shù)據(jù)的關(guān)系型視圖?？梢詫SON數(shù)據(jù)估算到關(guān)系型的行列之中，用戶可以對(duì)此函數(shù)返回的數(shù)據(jù)按照常規(guī)關(guān)系型數(shù)據(jù)表的方式進(jìn)行SQL運(yùn)算。

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陣列的聚合函數(shù)JSON_ARRAYAGG()，和用于生成JSON對(duì)象的JSON_OBJECTAGG()函數(shù)，令多行的JSON文檔組合成JSON陣列或者JSON對(duì)象成為可能。

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() 函數(shù)可執(zhí)行JavaScript的語法，在合并時(shí)發(fā)生重復(fù)鍵值對(duì)時(shí)將會(huì)優(yōu)先選用第二個(gè)文檔的鍵值對(duì)，并刪除第一個(gè)文檔對(duì)應(yīng)的重復(fù)鍵值。

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()函數(shù)與5.7版本中的JSON_MERGE()含義相同，都是在合并的時(shí)候保留所有值。

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() 函數(shù)在8.0版本中為減少merge操作的不明確，而被棄用。

8.0版本增加了可以接收J(rèn)SON原生數(shù)據(jù)類型和字符串表達(dá)的JSON，并返回一行縮進(jìn)的易讀的JSON格式化后的的字符串。

8.0版本增加了和指定JSON對(duì)象空間占用相關(guān)的函數(shù)，JSON_STORAGE_SIZE() 可以用字節(jié)為單位返回JSON某個(gè)數(shù)據(jù)類型的實(shí)際大小， JSON_STORAGE_FREE() 可以返回該JSON數(shù)據(jù)類型的剩余空間（包括碎片和用來適應(yīng)更改后發(fā)生長(zhǎng)度變化的預(yù)備空間）

8.0版本通過使用變長(zhǎng)的排序鍵提升了JSON排序分組的性能。在某些場(chǎng)景下，Preliminary 的壓測(cè)結(jié)果出現(xiàn)了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版本增加了對(duì) JSON_REMOVE(), JSON_SET() and JSON_REPLACE() 函數(shù)的部分更新的支持。如果JSON文檔的某部分被更新，我們會(huì)將更改的詳情給到句柄。這樣存儲(chǔ)引擎和復(fù)制關(guān)系就不必寫入整個(gè)JSON文檔。在之前的復(fù)制環(huán)境中由于無法確保JSON文檔的排列(layout)在主從上完全一致，所以在基于行的復(fù)制情況下物理文件的差異并不能用來削減傳輸復(fù)制信息帶來的網(wǎng)絡(luò)IO消耗。因此，8.0版本提供了在邏輯上區(qū)分差異的方法，可以在行復(fù)制的情況下傳輸并應(yīng)用到從庫(kù)上

地理信息系統(tǒng) GIS

8.0 版本提供對(duì)地形的支持，其中包括了對(duì)空間參照系的數(shù)據(jù)源信息的支持，SRS aware spatial數(shù)據(jù)類型，空間索引，空間函數(shù)?？偠灾?，8.0版本可以理解地球表面的經(jīng)緯度信息，而且可以在任意受支持的5000個(gè)空間參照系中計(jì)算地球上任意兩點(diǎn)之間的距離。

ST_SPATIAL_REFERENCE_SYSTEMS 存在于information schema視圖庫(kù)中，提供了可供使用的SRS坐標(biāo)系統(tǒng)的名稱。每個(gè)SRS坐標(biāo)系統(tǒng)都有一個(gè)SRID編號(hào)。8.0版本支持EPSG Geodetic Parameter Dataseset中的5千多個(gè)坐標(biāo)系統(tǒng)（包括立體模和2D平面地球模型）

空間類的數(shù)據(jù)類型可以直接從SRS坐標(biāo)系統(tǒng)的定義中獲取，例如：使用SRID 4326定義進(jìn)行建表： CREATE TABLE t1 (g GEOMETRY SRID 4326); 。SRID是適用于地理類型的數(shù)據(jù)類型。只有同一SRID的的數(shù)據(jù)才會(huì)被插入到行中。與當(dāng)前SRID數(shù)據(jù)類型的數(shù)據(jù)嘗試插入時(shí)，會(huì)報(bào)錯(cuò)。未定義SRID編號(hào)的表將可以接受所有SRID編號(hào)的數(shù)據(jù)。

8.0版本增加了 INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS 視圖，可以顯示當(dāng)前實(shí)例中所有地理信息的數(shù)據(jù)行及其對(duì)應(yīng)的SRS名稱，編號(hào)，地理類型名稱。

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.

在空間數(shù)據(jù)類型上可以創(chuàng)建空間索引，創(chuàng)建空間索引的列必須非空，例如： 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));

創(chuàng)建空間索引的列必須具有SRID數(shù)據(jù)標(biāo)識(shí)以用于優(yōu)化器使用，如果將空間索引建在沒有SRID數(shù)據(jù)標(biāo)識(shí)的列上，將輸出waring信息。

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

字符集 Character Sets

8.0版本默認(rèn)使用UTF8MB4作為默認(rèn)字符集。相比較5.7版本，SQL性能（諸如排序UTF8MB4字符串）得到了很大的提升。UTF8MB4類型在網(wǎng)頁(yè)編碼上正占據(jù)著舉足輕重的地位，將其設(shè)為默認(rèn)數(shù)據(jù)類型后，將會(huì)給絕大多數(shù)的MySQL用戶帶來遍歷。

• 默認(rèn)的字符集從latin1變?yōu)?utf8mb4 ,默認(rèn)排序校對(duì)規(guī)則從 latin1_swedish_ci 變?yōu)?code>utf8mb4_800_ci_ai。

  
  

• utf8mb4同樣也成為libmysql，服務(wù)端命令行工具,server層的默認(rèn)編碼

  
  

• utf8mb4同樣也成為MySQL測(cè)試框架的默認(rèn)編碼

• 排序校對(duì)規(guī)則的權(quán)重與大小寫基于Unicode委員會(huì)16年公布的Unicode 9.0.0版本。

  
  

• 在以往的MySQL版本中，latin1編碼中的21種語言的特殊大小寫和排序校對(duì)規(guī)則被引入了 utf8mb4 排序校對(duì)規(guī)則。例如：捷克語的排序校對(duì)規(guī)則變成了utf8mb4_cs_800_ai_ci。

  
  

• 增加了對(duì)特殊語境和重音敏感的排序校對(duì)規(guī)則的支持。8.0版本支持 DUCET (Default Unicode Collation Entry Table)全部三級(jí)排序校對(duì)規(guī)則。

  
  

• utf8mb4 的 utf8mb4_ja_0900_as_cs 排序校驗(yàn)規(guī)則對(duì)日語字符支持三級(jí)權(quán)重的排序。

  
  

• 對(duì)日語有額外的假名支持特性， utf8mb4_ja_0900_as_cs_ks中的ks表示假名區(qū)分。

  
  

• 把 Unicode 9.0.0之前所有排序校驗(yàn)規(guī)則中的不填補(bǔ)變成填補(bǔ)字符，此舉有利于提升字符串的一致性和性能。例如把字符串末尾的空格按照其他字符對(duì)待。之前的排序校驗(yàn)規(guī)則在處理這種情況時(shí)保留字符串原樣。

  
  

數(shù)據(jù)類型 Datatypes

8.0版本擴(kuò)展了 bit-wise操作（如bit-wise AND等）的使用范圍，使得其在所有 BINARY 數(shù)據(jù)類型上都適用。在此之前只支持整型數(shù)據(jù)，若強(qiáng)行在二進(jìn)制數(shù)據(jù)類型上使用Bit-wise操作，將會(huì)隱式轉(zhuǎn)換為64位的BITINT類型，并可能丟失若干位的數(shù)據(jù)。從8.0版本之后，bit-wise操作可以在 BINARY 和BLOB類型上使用，且不用擔(dān)心精確度下降的問題。

8.0版本通過支持 BINARY 上的Bit-wise操作提升了IPv6數(shù)據(jù)的可操作性。5.6版本中引入了支持IPv6地址和16位二進(jìn)制數(shù)據(jù)的互相轉(zhuǎn)換的INET6_ATON() 和 INET6_NTOA() 函數(shù)。但是直到8.0之前，由于上一段中的問題我們都無法講IPv6轉(zhuǎn)換函數(shù)和bit-wise操作結(jié)合起來。由于 INET6_ATON() 可以正確的返回128bit的VARBINARY(16)，如果我們想要將一個(gè)IPv6地址與網(wǎng)關(guān)地址進(jìn)行比對(duì)，現(xiàn)在就可以使用 INET6_ATON(address)& INET6_ATON(network) 操作。

8.0版本通過增加了三個(gè)新的函數(shù)（UUID_TO_BIN(), BIN_TO_UUID(), 和 IS_UUID()）提升了UUID的可用性。UUID_TO_BIN()可以將UUID格式的文本轉(zhuǎn)換成VARBINARY(16), BIN_TO_UUID()則與之相反， IS_UUID()用來校驗(yàn)UUID的有效性。將UUID以 VARBINARY(16) 的方式存儲(chǔ)后，就可以使用實(shí)用的索引了。 UUID_TO_BIN() 函數(shù)可以原本轉(zhuǎn)換后的二進(jìn)制數(shù)值中的時(shí)間相關(guān)位（UUID生成時(shí)有時(shí)間關(guān)聯(lián)）移到數(shù)據(jù)的開頭，這樣對(duì)索引來說更加友好而且可以減少在B樹中的隨機(jī)插入，從而減少了插入耗時(shí)。

消耗敏感的模型 Cost Model

8.0版本自動(dòng)地根據(jù)數(shù)據(jù)是否存在于內(nèi)存中而選擇查詢計(jì)劃，在以往的版本中，消耗敏感的模型始終假設(shè)數(shù)據(jù)在磁盤上。正因?yàn)楝F(xiàn)在查詢內(nèi)存數(shù)據(jù)和查詢硬盤數(shù)據(jù)的消耗常數(shù)不同，因此優(yōu)化器會(huì)根據(jù)數(shù)據(jù)的位置選擇更加優(yōu)化的讀取數(shù)據(jù)方式。

8.0版本加入了直方圖統(tǒng)計(jì)數(shù)據(jù)。用戶可以根據(jù)直方圖針對(duì)表中的某列（一般為非索引列）生成數(shù)據(jù)分布統(tǒng)計(jì)信息，這樣優(yōu)化器就可以利用這些信息去尋覓更加優(yōu)化的查詢計(jì)劃。直方圖最常見的使用場(chǎng)景就是計(jì)算字段的選擇性。

用以創(chuàng)建直方圖的 ANALYZE TABLE 語法現(xiàn)已被擴(kuò)展了兩個(gè)新子句： UPDATE HISTOGRAM ON column [, column] [WITH n BUCKETS] 和DROP HISTOGRAM ON column [, column]。直方圖的總計(jì)總數(shù)（桶）是可以選的，默認(rèn)100。直方圖的統(tǒng)計(jì)信息被存儲(chǔ)在詞典表column_statistics中，并可以使用information_schema.COLUMN_STATISTICS進(jìn)行查看。由于JSON數(shù)據(jù)格式的靈活性，直方圖現(xiàn)在以JSON對(duì)象存儲(chǔ)。根據(jù)表的大小，ANALYZE TABLE命令會(huì)自動(dòng)的判斷是否要表進(jìn)行采樣，甚至?xí)鶕?jù)表中數(shù)據(jù)的分布情況和統(tǒng)計(jì)總量來決定創(chuàng)建等頻或者等高的直方圖。

正則表達(dá)式 Regular Expressions

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

運(yùn)維自動(dòng)化特性 Dev Ops features

開發(fā)向的運(yùn)維關(guān)心數(shù)據(jù)庫(kù)實(shí)例的可操作型，通常即可靠性，可用性，性能，安全，可觀測(cè)性，可管理性。關(guān)于InnoDB Cluster和MGR的可靠性我們將會(huì)另起新篇單獨(dú)介紹，接下來的段落將會(huì)介紹關(guān)于8.0版本針對(duì)表在其他可操作性上的改變。

可靠性 Reliability

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

MySQL 8.0 increases the overall reliability of MySQL because :

8.0版本將元信息存儲(chǔ)與久經(jīng)考驗(yàn)的事務(wù)性存儲(chǔ)引擎InnoDB中。諸如用戶權(quán)限表，數(shù)據(jù)字典表，現(xiàn)在都使用   InnoDB進(jìn)行存儲(chǔ)。

8.0版本消除了會(huì)導(dǎo)致非一致性的一處隱患。在5.7及以前的版本中，存在著服務(wù)層和引擎層兩份數(shù)據(jù)字典，因而可能導(dǎo)致在故障情況下的數(shù)據(jù)字典間的同步失敗。在8.0版本中，只有一份數(shù)據(jù)字典。

8.0版本實(shí)現(xiàn)了原子化，無懼宕機(jī)的DDL。根據(jù)這個(gè)特性，DDL語句要么被全部執(zhí)行，要么全部未執(zhí)行。對(duì)于復(fù)制環(huán)境來說這是至關(guān)重要的，否則會(huì)導(dǎo)致主從之間因?yàn)楸斫Y(jié)構(gòu)不一致，數(shù)據(jù)漂移的情況。

基于新的事務(wù)型數(shù)據(jù)字典，可靠性得到了提高。

可觀測(cè)性 Observability

8.0版本重新實(shí)現(xiàn)了信息視圖庫(kù)，在新的實(shí)現(xiàn)中，信息視圖庫(kù)的表都是基于InnoDB存儲(chǔ)的數(shù)據(jù)字典表的簡(jiǎn)單視圖。這比之前有了百倍的性能提升。讓信息視圖庫(kù)可以更加實(shí)用性的被外部工具引用。

8.0版本通過在性能信息庫(kù)上增加了100多個(gè)索引完成了其查詢性能的提升。這些索引是預(yù)設(shè)，且無法被刪除，修改，增加。相對(duì)于在單獨(dú)的數(shù)據(jù)結(jié)構(gòu)上進(jìn)行便利，其索引是通過在既存數(shù)據(jù)表上過濾掃描來實(shí)現(xiàn)的。不需要管理B樹，或者散列表的重建，更新及其他操作。性能信息庫(kù)的索引從行為上更像散列索引：1，可以快速返回?cái)?shù)據(jù)，2，不支持排序操作（推到服務(wù)層處理）。根據(jù)查詢，索引會(huì)避免全表掃描的需求，而且會(huì)返回一個(gè)相當(dāng)精巧的數(shù)據(jù)集。對(duì)show indexes來說，性能信息庫(kù)的索引是不可見的，但是會(huì)出現(xiàn)在explain的結(jié)果中和其有關(guān)的部分。

8.0版本增加了關(guān)于配置參數(shù)的有用信息，比如變量名，最大最小值，當(dāng)前值的來源，更改用戶，更改時(shí)間等等。可以在一個(gè)新增的性能信息表variables_info表中進(jìn)行查詢。

8.0版本使得查看服務(wù)端曝出的客戶端錯(cuò)誤信息匯總統(tǒng)計(jì)成為可能。用戶可以在五個(gè)不同的表中查看統(tǒng)計(jì)信息：Global count, summary per thread, summary per user, summary per host, 和summary per account。

用戶可以查看單個(gè)錯(cuò)誤信息的次數(shù)，被SQL exception句柄處理過的數(shù)量，第一次發(fā)生的時(shí)間戳，最近一次的時(shí)間戳。給予用戶適當(dāng)?shù)臋?quán)限后，用戶既可以用select從中查詢，也可以使用truncate進(jìn)行重置統(tǒng)計(jì)數(shù)據(jù)。

為了更高的觀察查詢相應(yīng)時(shí)間，8.0版本在性能信息庫(kù)中提供了語句延遲的直方圖，同時(shí)會(huì)從直方圖中計(jì)算95%，99%，9999%比例的信息。這些百分比用來作為服務(wù)質(zhì)量的指示器。

8.0版本在性能信息庫(kù)中增加了數(shù)據(jù)鎖生產(chǎn)者身份。當(dāng)事務(wù)A鎖住行R時(shí)，事務(wù)B正在等待一行被A鎖住的行。新增的生產(chǎn)者身份將會(huì)那些數(shù)據(jù)被鎖?。ū纠袨樾蠷），誰擁有鎖（本例中為事務(wù)A），誰在等待被鎖住的事務(wù)（本例中為事務(wù)B）

8.0版本為了捕獲完成的查詢樣例和此查詢案例的一些關(guān)鍵信息，針對(duì)性能信息庫(kù)中的events_statements_summary_by_digest表做了一些改動(dòng)。為了捕獲一個(gè)真實(shí)的查詢，并讓用戶進(jìn)行explain，并獲取查詢計(jì)劃，現(xiàn)增加了一列QUERY_SAMPLE_TEXT 。為了捕獲查詢樣例時(shí)間戳，增加了一列QUERY_SAMPLE_SEEN 。為了捕獲查詢執(zhí)行時(shí)間，增加了一列 QUERY_SAMPLE_TIMER_WAIT 。同時(shí)FIRST_SEEN 和 LAST_SEEN 列被修改為可以使用帶小數(shù)的秒。

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

8.0版本 帶來了對(duì)錯(cuò)誤日志的重要的改革。從軟件架構(gòu)的角度來說，錯(cuò)誤日志成為了新的服務(wù)架構(gòu)的一部分。這意味著高級(jí)用戶可以根據(jù)需要寫出自己的錯(cuò)誤日志實(shí)現(xiàn)。雖然大多數(shù)用戶并不想這么做，但是或許會(huì)在如何寫，寫在何處上要求有些變通的空間。因此8.0版本為用戶提供了sinks和filters來實(shí)現(xiàn)。8.0版本實(shí)行了一個(gè)過濾服務(wù)（API），和一個(gè)默認(rèn)的過濾服務(wù)實(shí)現(xiàn)（組件）。這里的過濾器是指抑制某些特定錯(cuò)誤信息的數(shù)據(jù)和或給定錯(cuò)誤信息的某部分的輸出。8.0版本實(shí)行了一個(gè)日志撰寫（API），和一個(gè)默認(rèn)的日志撰寫服務(wù)實(shí)現(xiàn)（組件）。日志撰寫器可以接收日志信息，并將其寫入到日志中，這里的日志可以指典型的文件日志，syslog日志，或者JSON日志。

不做任何設(shè)置默認(rèn)的話，8.0版本帶來了開箱即用的錯(cuò)誤日志改進(jìn)。比如：

• 錯(cuò)誤編碼： 編碼格式現(xiàn)在為MY開頭的10000系列數(shù)據(jù)。比如： “MY-10001”。錯(cuò)誤編號(hào)在GA版本中將不會(huì)變化，但是其代表的含義可能在之后的維護(hù)性版本發(fā)布中做一些改變。

  
  

• 系統(tǒng)信息：系統(tǒng)性的信息[System]替換了之前的 [Error]（指之前錯(cuò)誤日志是系統(tǒng)性相關(guān)，但是前綴為[Error]的錯(cuò)誤信息）,增加到錯(cuò)誤日志中。

  
  

• 錯(cuò)誤日志詳細(xì)度減弱： 默認(rèn)的錯(cuò)誤日志詳細(xì)信息級(jí)別log_error_verbosity 從3(輸出)改成了2（輸出警告級(jí)別及以上）

  
  

• 信息源部分：每個(gè)信息前面都加了[Server], [InnoDB], [Replic] 三個(gè)其中之一的注釋，以顯示信息是從哪個(gè)子系統(tǒng)中輸出的。

  
  

8.0GA版本錯(cuò)誤日志中的啟動(dòng)信息：

新引入的錯(cuò)誤編碼方式允許 MySQL在需要的情況下在以后的維護(hù)性版本發(fā)布中，不改變錯(cuò)誤編號(hào)的情況下改進(jìn)錯(cuò)誤詳細(xì)信息。同時(shí)錯(cuò)誤編號(hào)還可以用于在客制化中作為過濾/屏蔽錯(cuò)誤信息的實(shí)施基礎(chǔ)。

可管理性 Manageability

8.0版本將索引的可見性管理變?yōu)榭赡堋Ｒ粋€(gè)不可見索引在優(yōu)化器指定查詢執(zhí)行計(jì)劃時(shí)不會(huì)被納入考慮。但是這個(gè)索引仍會(huì)在后臺(tái)維護(hù)，因此讓其變得可見比刪除再增加索引代價(jià)更小。設(shè)計(jì)不可見索引的目的時(shí)為了幫助DBA來判斷索引能否被刪除。如果你假設(shè)索引已經(jīng)不會(huì)被用到，可以先將其設(shè)為不可見，然后觀察查詢性能，如果相關(guān)的查詢性能沒有下降的話，最后可以將其刪除。這個(gè)功能也是萬眾期盼的。

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

Undo日志不在存放于系統(tǒng)表空間中：在版本升級(jí)的過程中，Undo日志被從系統(tǒng)表空間中分離出來，并放到Undo表空間中。這為現(xiàn)存的非獨(dú)立Undo表空間的升級(jí)留了后路。

1. 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表空間可以單獨(dú)管理：比如放到更快的磁盤存儲(chǔ)上。

2. Undo tablespaces can be managed separately from the System tablespace.For example, Undo tablespaces can be put on fast storage.

   在線Undo表空間回收：為了Undo表空間清理的需要，生成了了兩個(gè)小的Undo表空間，這樣可以讓InnoDB在一個(gè)活躍一個(gè)清理的情況下在線收縮Undo表空間。

3. 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.

   增多回滾段，減少爭(zhēng)用：現(xiàn)在用戶可以選擇使用最多127個(gè)Undo表空間，每個(gè)表空間都有最多可達(dá)128個(gè)回滾段。更多的回滾段可以讓并行的事務(wù)更可能地為其undo日志使用獨(dú)立的回滾段，這樣可以減少對(duì)同個(gè)資源的爭(zhēng)用。

4. 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.

在正常的情況下，全局的動(dòng)態(tài)的參數(shù)可以在線更改，但是實(shí)例重啟后，這些沒有寫入配置文件或者與配置文件沖突的參數(shù)設(shè)定值有可能會(huì)丟失。8.0版本中可以將全局的動(dòng)態(tài)參數(shù)的更改持久化。

這就讓 SET PERSIST sql_mode='STRICT_TRANS_TABLES';的寫法成為可能。這樣就可以在重啟后，參數(shù)設(shè)定值仍會(huì)留存。這個(gè)功能的使用場(chǎng)景很多，但是最重要的是給出了一個(gè)在更改配置文件不方便或者根本無法做到的情況下的選擇。比如某些托管的場(chǎng)景下，你根本沒有文件系統(tǒng)的訪問權(quán)限，僅有連入數(shù)據(jù)庫(kù)服務(wù)的權(quán)限。和 SET GLOBAL 相同，SET PERSIST也需要super權(quán)限。

除此之外還有 RESET PERSIST 命令，可以將之前使用SET PERSIST命令更改后參數(shù)值的持久化特性取消掉，讓這個(gè)參數(shù)值和 SET GLOBAL設(shè)置的一樣，下次啟動(dòng)可能會(huì)丟失。

8.0版本也允許對(duì)大部分當(dāng)前啟動(dòng)環(huán)境下的只讀參數(shù)進(jìn)行 SET PERSIST 更改，在下次啟動(dòng)時(shí)會(huì)生效。當(dāng)然了部分只讀參數(shù)是無法被設(shè)置更改的。

8.0版本增加了RESTART命令。其用途是用來允許通過SQL連接來允許遠(yuǎn)程管理MySQL實(shí)例。比如通過 SET PERSIST 命令更改了只讀參數(shù)后，可以用這個(gè)命令來重啟MySQL實(shí)例。當(dāng)然，需要shutdown權(quán)限（譯者注：同時(shí)mysqld進(jìn)程需要被supervisor進(jìn)程管理才可以。）。

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

8.0版本支持 ALTER TABLE ... RENAME COLUMN old_name TO new_name;，這相對(duì)于現(xiàn)有的ALTER TABLE <table_name> CHANGE …語法（需要注明當(dāng)前列所有屬性）來說是個(gè)改進(jìn)。應(yīng)用程序可能由于某些原因并不能獲取所該列的所有信息，因此，這是之前語法的弊端。同時(shí)之前的語法也可能會(huì)偶然導(dǎo)致數(shù)據(jù)丟失（rename應(yīng)該是在線DDL，不需要重建表）

MySQL 8.0 implements ALTER TABLE ... RENAME COLUMN old_name TO new_name;This is an improvement over existing syntax 

安全特性 Security features

8.0版本將默認(rèn)的驗(yàn)證插件從mysql_native_password改成了caching_sha2_password。與此對(duì)應(yīng)的，libmysqlclient也會(huì)采用caching_sha2_password驗(yàn)證機(jī)制。新的caching_sha2_password結(jié)合了更高的安全特性（SHA2算法）和高性能（緩存）。我們目前建議所有用戶在網(wǎng)絡(luò)通信上使用TLS/SSL。

8.0版本正在把OpenSSL作為企業(yè)版本和社區(qū)版本的統(tǒng)一默認(rèn)TLS/SSL庫(kù)。之前社區(qū)版本使用的是YaSSL。支持OpenSSL也是社區(qū)呼聲比較多的請(qǐng)求了。

8.0版本動(dòng)態(tài)的和OpenSSL鏈接在一起。從MySQL軟件源的使用者角度來看，現(xiàn)在MySQL包依賴于系統(tǒng)提供的OpenSSL文件。動(dòng)態(tài)的鏈接之后，OpenSSL的更新就不需要要求MySQL也一同更新或者打補(bǔ)丁。

8.0版本加入了對(duì)Undo和Redo日志的靜態(tài)加密。在5.7版本中，我們引入了對(duì)使用了獨(dú)立表空間的InnoDB表的加密。其可為物理的表空間數(shù)據(jù)文件提供靜態(tài)加密。在8.0版本中我們將這個(gè)貼行擴(kuò)展到了Undo和Redo日志上。

8.0版本引入了SQL角色。角色是一組權(quán)限的集合。其目的是為了簡(jiǎn)化用戶權(quán)限管理系統(tǒng)?？梢越巧x給用戶的身上，給角色授權(quán)，創(chuàng)建角色，刪除角色，定義哪些角色對(duì)于當(dāng)前會(huì)話是合適的。

8.0版本引入了可配置的參數(shù) mandatory-roles，用于自動(dòng)給新創(chuàng)建的用戶加上角色。授予給所有用戶指定的角色的權(quán)限不可以被再次分發(fā)。但是這些角色除非被設(shè)置為默認(rèn)角色，否則還是需要進(jìn)行激活操作。當(dāng)然也可以把新引入的 activate-all-roles-on-login參數(shù)設(shè)為ON，這樣在用戶驗(yàn)證通過連接進(jìn)來后，所有授權(quán)角色都會(huì)自動(dòng)激活。

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

8.0版本引入了一個(gè)新的系統(tǒng)權(quán)限 XA_RECOVER_ADMIN ，用于控制執(zhí)行 XA RECOVER語句的權(quán)限。所有嘗試執(zhí)行 XA RECOVER 語句的非授權(quán)用戶會(huì)引起報(bào)錯(cuò)。

8.0版本引入了對(duì)密碼重新使用的限制，既可以在全局層級(jí)也可以在單獨(dú)的用戶等級(jí)上配置。過往的歷史密碼由于安全的原因（會(huì)泄露密習(xí)慣，或者詞組）會(huì)被加密保存。密碼輪換策略對(duì)于其他策略來說是疊加的?？梢院同F(xiàn)有的機(jī)制（如，密碼過期和密碼安全策略等）共存。

8.0版本引入了在連續(xù)的錯(cuò)誤登陸嘗試后的等待驗(yàn)證過程。其設(shè)計(jì)目的用于減緩哦對(duì)用戶密碼的暴力破解。密碼連續(xù)錯(cuò)誤次數(shù)和連續(xù)錯(cuò)誤之后的等待時(shí)間是可以配置的。

8.0版本禁止當(dāng)實(shí)例以–skip-grant-tables參數(shù)啟動(dòng)時(shí)的遠(yuǎn)程用戶連接

8.0版本在實(shí)例中引入了部分之前mysqld_safe中的邏輯?？梢愿纳飘?dāng)使用 --daemonize 啟動(dòng)參數(shù)時(shí)在某些情況下的可用性。這也減輕了用戶對(duì)我們即將移除的mysqld-safe腳本的依賴。

性能 Performance

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

8.0版本對(duì)于讀寫皆有和高寫負(fù)載的拿捏恰到好處。在集中的讀寫均有的負(fù)載情況下，我們觀測(cè)到在4個(gè)用戶并發(fā)的情況下，對(duì)于高負(fù)載，和5.7版本相比有著兩倍性能的提高。在5.7上我們顯著了提高了只讀情況下的性能，8.0則顯著提高了讀寫負(fù)載的可擴(kuò)展性。為MySQL提升了硬件性能的利用率，其改進(jìn)是基于重新設(shè)計(jì)了InnoDB寫入Redo日志的方法。對(duì)比之前用戶線程之前互相爭(zhēng)搶著寫入其數(shù)據(jù)變更，在新的Redo日志解決方案中，現(xiàn)在Re'do日志由于其寫入和刷緩存的操作都有專用的線程來處理。用戶線程之間不在持有Redo寫入相關(guān)的鎖，整個(gè)Redo處理過程都是時(shí)間驅(qū)動(dòng)。

8.0版本允許馬力全開的使用存儲(chǔ)設(shè)備，比如使用英特爾奧騰閃存盤的時(shí)候，我們可以在IO敏感的負(fù)載情況下獲得1百萬的采樣 QPS（這里說的IO敏感是指不在IBP中，且必須從二級(jí)存儲(chǔ)設(shè)備中獲取）。這個(gè)改觀是由于我們擺脫了 file_system_mutex全局鎖的爭(zhēng)用。

8.0版本顯著地提升了高爭(zhēng)用負(fù)載下的性能。高爭(zhēng)用負(fù)載通常發(fā)生在許多事務(wù)爭(zhēng)用同一行數(shù)據(jù)的鎖，導(dǎo)致了事務(wù)等待隊(duì)列的產(chǎn)生。在實(shí)際情景中，負(fù)載并不是平穩(wěn)的，負(fù)載可能在特定的時(shí)間內(nèi)爆發(fā)（80/20法則）。8.0版本針對(duì)短時(shí)間的爆發(fā)負(fù)載無論在每秒處理的事務(wù)數(shù)（換句話，延遲）還是95%延遲上都處理的更好。對(duì)于終端用戶來說體現(xiàn)在更好的硬件資源利用率（效率）上。因?yàn)橄到y(tǒng)需要盡量使用榨盡硬件性能，才可以提供更高的平均負(fù)載。

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

其他特性 Other Features

在MySQL了團(tuán)隊(duì)中，為了更可能地讓用戶體驗(yàn)開箱即用，我們對(duì)MySQL的默認(rèn)值保持著緊密的關(guān)注。我們已經(jīng)更改了8.0版本中30多處參數(shù)為我們認(rèn)為更合適的默認(rèn)參數(shù)值。

8.0版本增加了關(guān)閉元數(shù)據(jù)產(chǎn)生并轉(zhuǎn)化成結(jié)果集的選項(xiàng)。構(gòu)建，解析，發(fā)送，接收元數(shù)據(jù)結(jié)果集都會(huì)消耗實(shí)例，客戶端和網(wǎng)絡(luò)的資源。在某些場(chǎng)景下，元數(shù)據(jù)大小可能比實(shí)際的結(jié)果集更大，且不必要。因此在我們關(guān)閉了元數(shù)據(jù)產(chǎn)生和存儲(chǔ)后，顯著了地提升了查詢結(jié)果集的轉(zhuǎn)化?？蛻舳巳绻幌虢邮沼跀?shù)據(jù)一同傳回的元數(shù)據(jù)信息，可以設(shè)置 CLIENT_OPTIONAL_RESULTSET_METADATA

8.0版本擴(kuò)展了 libmysql的C語言API，使其更加穩(wěn)定地從服務(wù)器流式獲取復(fù)制事務(wù)。其設(shè)計(jì)目的在于為了實(shí)現(xiàn)基于binlog的程序（類似Hadoop接收MySQL數(shù)據(jù)的工具） 進(jìn)而需要避免對(duì)非正式API的調(diào)用和對(duì)內(nèi)部頭文件的打包

8.0版本利用多樣的的get操作和對(duì)范圍查詢的支持，提升了InnoDB的內(nèi)存緩存技能。我們通過對(duì)多種get操作的支持還提升了讀性能，如用戶可以在單次內(nèi)存緩存查詢中獲取多個(gè)鍵值對(duì)。對(duì)范圍查詢的支持是應(yīng)臉書的Yoshinori 所請(qǐng)求（譯者注：MHA作者）。利用范圍查詢，用戶可以指定一個(gè)特定的范圍，并獲取此區(qū)間所有合乎需要的鍵值。這兩個(gè)特性對(duì)于減少客戶端和服務(wù)端的來回交互來說都是至關(guān)重要的。

8.0版本通過寫入redo日志，持久化了自增計(jì)數(shù)器。持久化的自增計(jì)數(shù)器解決了一個(gè)年代悠久的BUG（譯者注：實(shí)例在重啟后，自增計(jì)數(shù)器重復(fù)利用了之前被使用后刪除的自增值）。MySQL恢復(fù)進(jìn)程會(huì)重放redo日志，以確保自增計(jì)數(shù)器的準(zhǔn)確數(shù)值。不再會(huì)出現(xiàn)自增值計(jì)數(shù)器數(shù)值的回滾。這意味著數(shù)據(jù)庫(kù)實(shí)例在故障恢復(fù)時(shí)會(huì)將redo日志中最后一次發(fā)放的自增值作為重建計(jì)數(shù)器的起點(diǎn)。確保了自增計(jì)數(shù)器的值不會(huì)重復(fù)發(fā)放，計(jì)數(shù)器的數(shù)值是單調(diào)遞增的。但要注意可能會(huì)有空洞（即發(fā)放但是未使用的自增值）。未持久化的自增值在過去一直被認(rèn)為是一個(gè)的有麻煩的故障點(diǎn)。

總結(jié) 

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

當(dāng)然你也可以從既存的5.7實(shí)例升級(jí)到8.0版本。在此過程中，你可能需要試試我們隨著shell工具包一同下發(fā)的新的升級(jí)檢查工具。這個(gè)工具可以幫你檢查既存5.7版本的8.0版本升級(jí)兼容性（譯者附：8.0.3到8.0.11不可以直接升級(jí)，或許我用到了舊的工具，改天再試）?？梢栽囋嘑rédéric Descamps寫的t Migrating to MySQL 8.0 without breaking old application 博文。

在這篇文章中我們主要覆蓋了服務(wù)端的新特性。不僅如此，我們還寫了很多關(guān)于其他方面的文章，如復(fù)制，組復(fù)制，InnoDB集群，MySQL Shell,開發(fā)API及其相關(guān)的連接組件（(Connector/Node.js, Connector/Python, PHP, Connector/NET, 

關(guān)于MySQL8.0 GA版本的新特性有哪些就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。