这篇文章将为大家详细讲解有关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进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
