MySQL 8.0 正式版 8.0.11 已发布，官方表示 MySQL 8 要比 MySQL 5.7 快 2 倍，还带来了大量的改进和更快的性能！
注意：从 MySQL 5.7 升级到 MySQL 8.0 仅支持通过使用 in-place 方式进行升级，并且不支持从 MySQL 8.0 降级到 MySQL 5.7（或从某个 MySQL 8.0 版本降级到任意一个更早的 MySQL 8.0 版本）。唯一受支持的替代方案是在升级之前对数据进行备份。
MySQL 8.0是全球最受欢迎的开源数据库的一个非常令人兴奋的新版本，全面改进。一些关键的增强包括：
SQL窗口函数，公用表表达式，NOWAIT和SKIP LOCKED，降序索引，分组，正则表达式，字符集，成本模型和直方图。
JSON扩展语法，新功能，改进排序和部分更新。使用JSON表函数，您可以使用JSON数据的SQL机制。
GIS地理支持。空间参考系统（SRS），以及SRS感知空间数据类型，空间索引和空间功能。
可靠性 DDL语句已变得原子性和崩溃安全，元数据存储在单个事务数据字典中。由InnoDB提供支持！
可观察性性能架构，信息架构，配置变量和错误记录的显着增强。
可管理性远程管理，撤消表空间管理和新的即时DDL。
安全 OpenSSL改进，新的默认身份验证，SQL角色，分解超级特权，密码强度等等。
性能 InnoDB在读/写工作负载，IO绑定工作负载和高争用“热点”工作负载方面明显更好。增加了资源组功能，通过将用户线程映射到CPU，为用户提供一个选项，以针对特定硬件上的特定工作负载进行优化
开发者功能
MySQL开发人员需要新功能，而MySQL 8.0在诸如SQL，JSON，正则表达式和GIS等领域提供了许多新的和更多需求的功能。开发人员也希望能够存储Emojis，因此UTF8MB4现在是8.0中的默认字符集。最后，数据类型得到了改进，在BINARY数据类型上进行了按位操作，并且改进了IPv6和UUID功能。
下面简要介绍 MySQL 8 中值得关注的新特性和改进。
1. 性能：MySQL 8.0 的速度要比 MySQL 5.7 快 2 倍。MySQL 8.0 在以下方面带来了更好的性能：读/写工作负载、IO 密集型工作负载、以及高竞争（"hot spot"热点竞争问题）工作负载。
2. NoSQL：MySQL 从 5.7 版本开始提供 NoSQL 存储功能，目前在 8.0 版本中这部分功能也得到了更大的改进。该项功能消除了对独立的 NoSQL 文档数据库的需求，而 MySQL 文档存储也为 schema-less 模式的 JSON 文档提供了多文档事务支持和完整的 ACID 合规性。
3. 窗口函数(Window Functions)：从 MySQL 8.0 开始，新增了一个叫窗口函数的概念，它可以用来实现若干新的查询方式。窗口函数与 SUM()、COUNT() 这种集合函数类似，但它不会将多行查询结果合并为一行，而是将结果放回多行当中。即窗口函数不需要 GROUP BY。
4. 隐藏索引：在 MySQL 8.0 中，索引可以被“隐藏”和“显示”。当对索引进行隐藏时，它不会被查询优化器所使用。我们可以使用这个特性用于性能调试，例如我们先隐藏一个索引，然后观察其对数据库的影响。如果数据库性能有所下降，说明这个索引是有用的，然后将其“恢复显示”即可；如果数据库性能看不出变化，说明这个索引是多余的，可以考虑删掉。
5. 降序索引：MySQL 8.0 为索引提供按降序方式进行排序的支持，在这种索引中的值也会按降序的方式进行排序。
6. 通用表表达式(Common Table Expressions CTE)：在复杂的查询中使用嵌入式表时，使用 CTE 使得查询语句更清晰。
7. UTF-8 编码：从 MySQL 8 开始，使用 utf8mb4 作为 MySQL 的默认字符集。
8. JSON：MySQL 8 大幅改进了对 JSON 的支持，添加了基于路径查询参数从 JSON 字段中抽取数据的 JSON_EXTRACT() 函数，以及用于将数据分别组合到 JSON 数组和对象中的 JSON_ARRAYAGG() 和 JSON_OBJECTAGG() 聚合函数。
9. 可靠性：InnoDB 现在支持表 DDL 的原子性，也就是 InnoDB 表上的 DDL 也可以实现事务完整性，要么失败回滚，要么成功提交，不至于出现 DDL 时部分成功的问题，此外还支持 crash-safe 特性，元数据存储在单个事务数据字典中。
10. 高可用性(High Availability)：InnoDB 集群为您的数据库提供集成的原生 HA 解决方案。
11. 安全性：对 OpenSSL 的改进、新的默认身份验证、SQL 角色、密码强度、授权。
详细说明：
窗口函数
MySQL 8.0提供了SQL窗口功能。与分组集合函数类似，窗口函数对一组行进行一些计算，例如COUNT或SUM。但是，如果分组聚合将这组行集合到一行中，则窗口函数将为结果集中的每一行执行聚合。
窗口函数有两种形式：用作窗口函数和专用窗口函数的SQL聚合函数。这是MySQL中支持窗口化的集合函数集合：COUNT，SUM，AVG，MIN，MAX，BIT_OR，BIT_AND，BIT_XOR，STDDEV_POP（及其同义词STD，STDDEV），STDDEV_SAMP，VAR_POP（及其同义词VARIANCE）和VAR_SAMP。这组专门的窗口函数是：RANK，DENSE_RANK，PERCENT_RANK，CUME_DIST，NTILE，ROW_NUMBER，FIRST_VALUE，LAST_VALUE，NTH_VALUE，LEAD和LAG
对窗口函数（又名分析函数）的支持是一种频繁的用户请求。窗口函数一直是标准SQL（SQL 2003）的一部分。在这里可以看到Dag Wanvik的 博客文章以及Guilhem Bichot 在这里的博客文章。
公用表表达式
MySQL 8.0提供[递归]公用表表达式（CTE）。非递归CTE可以解释为“改进的派生表”，因为它允许派生表被多次引用。递归CTE是一组迭代构建的行：从最初的一组行开始，一个进程派生新的行，然后将这些新的行重新输入到进程中，产生更多的行，等等，直到该过程不再生成行。CTE是一个通常需要的SQL功能，请参阅功能请求16244和32174。见吉扬Bichot博客文章在这里，这里，这里和这里。
NOWAIT和SKIP LOCKED
MySQL的8.0提供了NOWAIT与SKIP LOCKED该SQL锁定子句中的替代品。通常，当某行由于某个UPDATE或某一行而被锁定时SELECT ... FOR UPDATE，任何其他事务都必须等待才能访问该锁定的行。在某些使用情况下，如果行被锁定或忽略锁定行，则需要立即返回。使用锁定子句NOWAIT永远不会等待获取行锁。相反，查询将失败并显示错误。使用锁定子句SKIP LOCKED永远不会等待获取列出的表上的行锁。相反，锁定的行将被跳过并且不会被读取。NOWAIT和SKIP LOCKED是经常请求的SQL功能。请参阅功能请求49763。我们也想对Kyle Oppenheim 说声谢谢为他的代码贡献！请参阅Martin Hansson 在这里发表的博文。
GROUPING
MySQL 8.0提供GROUPING()，SQL_FEATURE T433。该GROUPING()功能区分超常规行与常规分组行。GROUP BY诸如ROLLUP产生超集合行的扩展，其中所有值的集合由空值表示。使用该GROUPING()函数，您可以区分表示超常聚合行中所有值的集合的null与NULL常规行中的值。GROUPING是一个频繁请求的SQL功能。请参阅功能请求3156和46053。感谢Zoe Dong和Shane Adams在功能请求46053中的代码贡献！见Chaithra Gopalareddy博客文章 在这里。
优化器提示
在5.7中，我们为优化器提示引入了一种新的提示语法。使用新的语法，可以SELECT | INSERT | REPLACE | UPDATE | DELETE在SQL语句中的关键字之后直接指定提示，并将其用/*+ */风格注释括起来。（见这里的Sergey Glukhov博客文章5.7 ）。在MySQL 8.0中，我们通过充分利用这种新风格来完成图片：
MySQL 8.0增加了INDEX_MERGE和的提示NO_INDEX_MERGE。这允许用户在不更改优化器开关的情况下控制单个查询的索引合并行为。
MySQL的8.0增加了用于提示JOIN_FIXED_ORDER，JOIN_ORDER，JOIN_PREFIX，和JOIN_SUFFIX。这允许用户控制联合执行的表顺序。
MySQL 8.0添加了一个叫做提示SET_VAR。该SET_VAR提示将针对只剩下一语句给定的系统变量设置的值。因此，语句结束后，该值将重置为先前的值。在这里可以看到Sergey Glukhov的博客文章。
我们更倾向于将新风格的优化器提示视为优于旧式提示和optimizer_switch值设置。通过不与SQL混合，新的提示可以在查询字符串中的许多地方注入。他们在提示（vs指令）方面也有更清晰的语义。
JSON
MySQL 8.0增加了新的JSON函数，并提高了排序和分组JSON值的性能。
JSON路径表达式中的范围的扩展语法
MySQL 8.0扩展了JSON路径表达式中范围的语法。例如SELECT JSON_EXTRACT('[1, 2, 3, 4, 5]', '$[1 to 3]');结果[2, 3, 4]。引入的新语法是SQL标准语法的一个子集，在SQL：2016，9.39 SQL / JSON路径语言中描述：语法和语义。参见Roland Bouman所报告的Bug＃79052。
JSON表函数
MySQL 8.0增加了JSON表函数，可以使用JSON数据的SQL机制。JSON_TABLE()创建JSON数据的关系视图。它将JSON数据评估的结果映射到关系行和列。用户可以使用SQL查询函数返回的结果为常规关系表，例如join，project和aggregate。
JSON聚合函数
MySQL 8.0添加了聚合函数JSON_ARRAYAGG()来生成JSON数组并JSON_OBJECTAGG()生成JSON对象。这使得将多行中的JSON文档组合成JSON数组或JSON对象成为可能。见克特林Besleaga博客文章在这里。
JSON合并函数
该JSON_MERGE_PATCH()函数实现RFC7396指定的JavaScript（和其他脚本语言）的语义，即它通过第二个文档的优先级去除重复项。例如，。JSON_MERGE('{"a":1,"b":2 }','{"a":3,"c":4 }'); # returns {"a":3,"b":2,"c":4}
例如，该JSON_MERGE_PRESERVE()函数具有在MySQL 5.7中实现的JSON_MERGE（）的语义，该语法保留所有值 JSON_MERGE('{"a": 1,"b":2}','{"a":3,"c":4}'); # returns {"a":[1,3],"b":2,"c":4}.
现有的JSON_MERGE()函数在MySQL 8.0中不推荐使用，以消除合并操作的歧义。请参阅Bug＃81283中的提案以及Morgan Tocker 在此处的博文。
JSON漂亮功能
MySQL 8.0 JSON_PRETTY()在MySQL中添加了一个函数。该函数接受JSON本机数据类型或JSON的字符串表示形式，并以新的行和缩进方式以人类可读的方式返回JSON格式的字符串。
JSON大小函数
MySQL 8.0为给定的JSON对象添加了与空间使用相关的JSON函数。该JSON_STORAGE_SIZE()回报的JSON数据类型字节的实际大小。在JSON_STORAGE_FREE()返回以字节为单位，包括分段和填充保存就地更新一个JSON二进制类型的自由空间。
JSON改进排序
MySQL 8.0通过使用可变长度的排序键为排序/分组JSON提供了更好的性能。初步的基准测试显示，根据使用情况，分类的改进度提高了1.2至18倍。
JSON部分更新
MySQL的8.0增加了对部分更新支持JSON_REMOVE()，JSON_SET()以及JSON_REPLACE()功能。如果只更新JSON文档的某些部分，我们希望向处理程序提供有关更改内容的信息，以便存储引擎和复制无需编写完整文档。在复制环境中，无法保证JSON文档的布局在从属设备和主设备上完全相同，因此物理差异无法用于减少基于行复制的网络I / O。因此，MySQL 8.0提供了逻辑差异，即基于行的复制可以通过线路发送并在从属设备上重新应用。见克努特安德斯·哈特兰的博客文章在这里。
GIS
MySQL 8.0提供地理支持。这包括对空间参考系统（SRS）的元数据支持，以及SRS感知空间数据类型，空间索引和空间函数。简而言之，MySQL 8.0可以理解地球表面的纬度和经度坐标，例如，可以在大约5000个支持的空间参考系统中的任何一个中正确计算地球表面上两点之间的距离。
空间参考系统（SRS）
的ST_SPATIAL_REFERENCE_SYSTEMS信息模式视图提供有关空间数据可用的空间参考系统的信息。该视图基于SQL / MM（ISO / IEC 13249-3）标准。每个空间参考系统都由一个SRID号码标识。MySQL 8.0附带来自EPSG大地参数数据集的大约5000个SRID ，涵盖地理参考椭球和2d投影（即所有2D空间参考系统）。
SRID感知空间数据类型
空间数据类型可以用空间参考系统定义进行归属，例如SRID 4326，如下所示：CREATE TABLE t1 (g GEOMETRY SRID 4326);SRID在这里是GEOMETRY数据类型的SQL类型修饰符。插入具有SRID属性的列中的值必须位于该SRID中。尝试使用其他SRID插入值会导致引发异常情况。未修改的类型（即没有SRID规范的类型）将继续接受所有SRID，如前所述。
MySQL 8.0添加了INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNSSQL / MM第3部分中指定的视图。19.2。这种观点将列出所有几何列在MySQL实例，并为每列将列出标准SRS_NAME，SRS_ID和GEOMETRY_TYPE_NAME。
SRID感知空间索引
空间索引可以在空间数据类型上创建。空间索引中的列必须声明为NOT NULL。例如像这样：CREATE TABLE t1 (g GEOMETRY SRID 4326 NOT NULL, SPATIAL INDEX(g));
具有空间索引的列应该具有SRID类型修饰符，以允许优化器使用索引。如果在没有SRID类型修饰符的列上创建空间索引，则会发出警告。
SRID感知空间功能
MySQL的8.0延伸的空间的功能，例如 ST_Distance()和ST_Length()来检测其参数是在一个地理（椭圆形）和SRS来计算对椭球的距离。到目前为止，ST_Distance和空间关系，例如ST_Within，ST_Intersects，ST_Contains，ST_Crosses，等支持地理计算。每个ST函数的行为如SQL / MM Part 3 Spatial中所定义。
字符集
MySQL 8.0使UTF8MB4成为默认字符集。SQL性能 - 比如对UTF8MB4字符串进行排序 - 与5.7相比，8.0版本的性能提高了20倍。UTF8MB4是网络中主要的字符编码，这一举措将使绝大多数MySQL用户的生活更轻松。
默认字符集已从更改latin1为utf8mb4并且默认排序规则从更改latin1_swedish_ci为utf8mb4_800_ci_ai。
默认值的更改适用于libmysql和服务器命令工具以及服务器本身。
这些更改也反映在MTR测试中，使用新的默认字符集运行。
整理重量和案例映射基于Unicode 9.0.0，由Unicode委员会于2016年6月21日发布。
已针对latin1（MySQL遗留版）使用了21种语言特定的不区分大小写排序规则 utf8mb4，例如捷克语排序规则变为utf8mb4_cs_800_ai_ci。请参阅WL＃9108中的完整列表。在这里可以看到Xing Zhang的博客文章。
增加了对区分大小写和区分变音的支持。MySQL 8.0支持由DUCET（默认Unicode排序规则表）定义的所有3级归类权重。在这里可以看到Xing Zhang的博客文章。
使用三个等级的重量排序字符的日语utf8mb4_ja_0900_as_cs整理utf8mb4。这给了日文正确的排序顺序。在这里可以看到Xing Zhang的博客文章。
日语有额外的假名敏感功能，utf8mb4_ja_0900_as_cs_ks其中'ks'代表'假名敏感'。在这里可以看到Xing Zhang的博客文章。
将所有新的排序规则从Unicode 9.0.0向前更改为NO PAD替代PAD STRING，即将字符串末尾的空格像其他任何字符一样处理。这样做是为了提高一致性和性能。较旧的排序规则留在原地。
看到的Bernt马里乌斯·约翰森也是博客文章在这里，这里和这里。
数据类型
二进制数据类型的按位操作
MySQL 8.0扩展了按位操作（'按位AND'等）以便使用[VAR]BINARY/[TINY|MEDIUM|LONG]BLOB。8.0之前的位操作仅支持整数。如果在二进制文件上使用按位BIGINT操作，则在操作之前将参数隐式转换为（64位），因此可能会丢失位。从8.0开始，逐位操作适用于所有数据类型BINARY和BLOB数据类型，可以输出参数以避免丢失位。
IPV6操纵
MySQL 8.0通过支持BINARY数据类型的按位操作来提高IPv6操作的可用性。在MySQL 5.6我们介绍了INET6_ATON()和INET6_NTOA()其将文本形式等之间的IPv6地址的功能'fe80::226:b9ff:fe77:eb17'和VARBINARY(16)。但是，到目前为止，我们无法将这些IPv6功能与按位操作相结合，因为这些操作会错误地将输出转换为BIGINT。例如，如果我们有一个IPv6地址并且想要针对网络掩码进行测试，我们现在可以使用，因为它可以 正确返回数据类型（128位）。见克特林Besleaga博客文章在这里。INET6_ATON(address)
& INET6_ATON(network)INET6_ATON()VARBINARY(16)
UUID操作
MySQL的8.0通过实现三个新的SQL函数提高UUID操作的易用性：UUID_TO_BIN()，BIN_TO_UUID()，和IS_UUID()。第一个从UUID格式化文本转换VARBINARY(16)为第二个VARBINARY(16)到UUID格式化文本，最后一个检查UUID格式文本的有效性。存储为a的UUID VARBINARY(16)可以使用功能索引进行索引。功能UUID_TO_BIN()和UUID_TO_BIN()也可以洗牌与时间相关的位，在开始移动它们使得指数友好，避免在B树中的随机插入，这样降低了插入时间。这种功能的缺乏被认为是使用UUID的缺点之一。见克特林Besleaga博客文章在这里。
成本模型
查询优化器将数据缓冲考虑在内
MySQL 8.0根据有关数据是驻留在内存还是磁盘上的知识来选择查询计划。这是自动发生的，从最终用户可以看出，没有涉及配置。历史上，MySQL成本模型假定数据驻留在旋转磁盘上。与在内存和磁盘上查找数据相关的成本常数现在不同，因此，根据对数据位置的了解，优化程序将为这两种情况选择更优化的访问方法。在这里查看ØysteinGrøvlen的博客文章。
优化器直方图
MySQL 8.0实现了直方图统计。通过使用直方图，用户可以创建表格中列的数据分布统计信息，通常针对非索引列进行，然后查询优化器将使用这些统计信息来查找最佳查询计划。直方图统计的主要用途是计算形式为“COLUMN CONSTANT”的谓词的选择性（过滤效果）。
用户通过ANALYZE TABLE已扩展为接受两个新子句的语法创建直方图：UPDATE HISTOGRAM ON column [, column] [WITH n BUCKETS]和DROP HISTOGRAM ON column [, column]。桶的数量是可选的，默认值是100.直方图统计信息存储在字典表“column_statistics”中，可通过视图访问information_schema.COLUMN_STATISTICS。由于JSON数据类型的灵活性，直方图存储为JSON对象。ANALYZE TABLE 将根据表大小自动决定是否采样基准表。它还将根据数据分布和指定的桶数来决定是建立一个singleton还是一个等高直方图。在这里可以看到ErikFrøseth的博客文章。
常用表达
MySQL的8.0支持UTF8MB4正则表达式，以及像新的功能REGEXP_INSTR()，REGEXP_LIKE()，REGEXP_REPLACE()，和REGEXP_SUBSTR()。已经添加了系统变量regexp_stack_limit（默认32步）和regexp_time_limit（默认8000000字节）来控制执行。该REGEXP_REPLACE() 功能是MySQL社区最需要的功能之一，例如，请参阅由Hans Ginzel 报告BUG＃27389的功能请求。另见马丁汉森在这里和博尔特马里乌斯约翰森在这里的博客文章。
Dev Ops功能
Dev Ops关注数据库的运营方面，通常涉及可靠性，可用性，性能，安全性，可观察性和可管理性。高可用性附带了MySQL InnoDB集群和MySQL组复制，将由单独的博客文章进行介绍。下面是8.0在其他类别中带来的东西。
可靠性
MySQL 8.0增加了MySQL的整体可靠性，因为：
MySQL 8.0将其元数据存储到InnoDB中，这是一种久经考验的事务性存储引擎。系统表（如Users和Privileges以及Data Dictionary表）现在驻留在InnoDB中。
MySQL 8.0消除了潜在不一致的一个来源。在5.7和更早版本中，基本上有两个数据字典，一个用于服务器层，另一个用于InnoDB层，在某些崩溃的情况下这些数据字典可能不同步。在8.0中只有一个数据字典。
MySQL 8.0确保原子的，崩溃安全的DDL。有了这个，用户可以保证任何DDL语句将被完全执行或根本不执行。这在复制环境中尤为重要，否则可能会出现主节点和从节点（节点）不同步的情况，从而导致数据漂移。
这项工作是在新的事务数据字典的背景下完成的。在这里和这里查看Staale Deraas的博客文章。
观测
信息模式（加速）
MySQL 8.0重新实现了信息模式。在新的实现中，Information Schema表格是存储在InnoDB中的数据字典表的简单视图。这比旧的实施效率高出100倍，效率更高。这使信息模式可以通过外部工具实际使用。在这里和这里查看Gopal Shankar 的博客文章，以及StåleDeraas 在这里的博客文章。
性能架构（加速）
MySQL 8.0通过在性能架构表上添加超过100个索引来加速性能架构查询。性能架构表上的索引是预定义的。他们不能被删除，添加或更改。性能模式索引是作为对现有表数据的过滤扫描来实现的，而不是通过单独的数据结构进行遍历。没有B树或散列表需要构建，更新或以其他方式管理。性能架构表索引在散列索引中的行为如下：a）它们快速检索所需的行，并且b）不提供行排序，并在必要时让服务器对结果集进行排序。但是，根据查询，索引可以避免使用全表扫描，并返回相当小的结果集。性能模式索引可用SHOW INDEXES并在EXPLAIN输出中表示引用索引列的查询。见Simon Mudd的评论。在这里查看Marc Alff的博文。
配置变量
MySQL的8.0增加了对配置变量，如变量名，有用的信息最小/最大值，这里 的电流值是从哪里来的， 谁进行了更改，并在它被做。该信息位于名为的新性能模式表中 variables_info。在这里可以看到Satish Bharathy的博客文章。
客户端错误报告 - 消息计数
MySQL 8.0可以查看服务器报告的客户端错误消息的聚合计数 。用户可以查看来自5个不同表格的统计信息：全局计数，每个线程的汇总，每个用户的汇总，每个主机的汇总或每个账户的汇总。对于每条错误消息，用户都可以看到引发错误的数量，由SQL异常处理程序处理的错误数，“首次看到”时间戳和“上次看到”时间戳。给定正确的权限，用户可以SELECT从这些表TRUNCATE中重置统计信息。在这里可以看到Mayank Prasad的博客文章。
语句延迟柱状图
为了更好地查看查询响应时间，MySQL 8.0提供了语句延迟的性能模式直方图。这项工作还从收集的直方图中计算“P95”，“P99”和“P999”百分位数。这些百分比可以用作服务质量的指标。见弗雷德里克DESCAMPS博客文章在这里。
数据锁定相关性图
MySQL 8.0仪器数据锁定在性能模式中。当事务A锁定R行，并且事务B在这个同一行上等待时，B被A有效阻止。添加的检测揭示哪些数据被锁定（R），谁拥有锁（A），谁在等待数据（B）。见弗雷德里克DESCAMPS博客文章在这里。
摘要查询示例
MySQL 8.0对events_statements_summary_by_digest性能模式表进行了一些更改，以捕获完整的示例查询和关于此查询示例的一些关键信息。QUERY_SAMPLE_TEXT添加该列以捕获查询示例，以便用户可以在真实查询上运行EXPLAIN并获取查询计划。该列QUERY_SAMPLE_SEEN被添加以捕获查询样本时间戳。该列QUERY_SAMPLE_TIMER_WAIT被添加以捕获查询样本执行时间。列FIRST_SEEN和LAST_SEEN 已被修改为使用小数秒。见弗雷德里克DESCAMPS博客文章 在这里。
有关仪器的元数据
MySQL 8.0将元数据（如属性，易变性和文档）添加到性能架构表 setup_instruments。这种只读元数据可作为仪器的在线文档，供用户或工具查看。见弗雷德里克DESCAMPS博客文章在这里。
错误记录
MySQL 8.0对MySQL 错误日志进行了重大改进。从软件体系结构的角度来看，错误日志是新服务基础架构中的一个组件。这意味着高级用户可以根据需要编写自己的错误日志实现。大多数用户不想编写他们自己的错误日志实现，但仍然希望在编写和编写它的地方有一定的灵活性。因此，8.0为用户提供设施来添加汇（哪里）和过滤器（什么）。MySQL 8.0实现了一个过滤服务（API）和一个默认的过滤服务实现（组件）。这里的过滤意味着禁止给定日志消息（投影）中的某些日志消息（选择）和/或字段。MySQL 8.0实现了日志编写器服务（API）和默认日志编写器服务实现（组件）。日志编写者接受日志事件并将其写入日志。该日志可以是经典文件，syslog，EventLog和新的JSON日志编写器。
默认情况下，没有任何配置，MySQL 8.0提供了许多现成的错误日志改进，例如：
错误编号：格式是10000系列中以“MY-”开头的数字，例如“MY-10001”。GA版本中的错误编号将保持稳定，但在维护版本中允许相应的错误文本发生变化（即改进）。
系统消息：系统消息以[系统]而不是[错误]，[警告]，[注意]的形式写入错误日志。无论详细情况如何，都会打印[系统]和[错误]消息，且无法取消。[系统]消息仅在少数地方使用，主要与主要状态转换相关，例如启动或停止服务器。
减少详细程度：log_error_verbosity的默认值从3（注释）变为2（警告）。这使得MySQL 8.0错误日志在默认情况下不会变得冗长。
源组件：每个消息都用三个值[Server]，[InnoDB]，[Replic]中的一个注释来显示消息来自哪个子系统。
这是启动后写入8.0 GA错误日志的内容：
2018-03-08T10:14:29.289863Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.5) starting as process 8063
2018-03-08T10:14:29.745356Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2018-03-08T10:14:29.765159Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.5' socket: '/tmp/mysql.sock' port: 3306 Source distribution.
2018-03-08T10:16:51.343979Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.5) Source distribution.
1
2
3
4
2018-03-08T10:14:29.289863Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.5) starting as process 8063
2018-03-08T10:14:29.745356Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2018-03-08T10:14:29.765159Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.5' socket: '/tmp/mysql.sock' port: 3306 Source distribution.
2018-03-08T10:16:51.343979Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.5) Source distribution.
在错误日志中引入错误编号可以让MySQL在即将发布的维护版本（如果需要）中改进错误文本，同时保持错误编号（ID）不变。错误编号也是过滤/压制和国际化/本地化的基础。
可管理性
INVISIBLE索引
MySQL 8.0增加了切换索引可见性（可见/不可见）的功能。优化器在执行查询执行计划时不会考虑不可见索引。但是，该指数仍保留在后台，因此再次显示该指标非常便宜。这样做的目的是让DBA / DevOp确定是否可以删除索引。如果您怀疑没有使用索引，则首先使其不可见，然后监视查询性能，如果没有遇到查询减慢的情况，最后删除索引。很多用户都要求这个功能，例如Bug＃70299。请参阅Martin Hansson 在这里发表的博文。
灵活撤消表空间管理
MySQL 8.0为用户提供了完全控制撤消表空间的能力，例如，有多少个表空间，它们放置在哪里以及每个表空间的回滚段数。
不再有撤消登录系统表空间。撤消日志在升级过程中从系统表空间迁移到撤消表空间。这为使用用于撤消日志的系统表空间的现有5.7安装提供了升级路径。
撤销表空间可以与系统表空间分开管理。例如，撤消表空间可以放在快速存储上。
回收异常大型交易占用的空间（在线）。创建至少两个撤销表空间以允许表空间截断。这允许InnoDB收缩撤消表空间，因为一个撤消表空间可以被激活而另一个被截断。
更多的回滚段导致争用更少。用户可能会选择最多127个撤消表空间，每个表空间最多有128个回滚段。更多的回滚段意味着并发事务更可能为其撤消日志使用单独的回滚段，从而减少对相同资源的争用。
在这里查看凯文刘易斯的博客文章。
SET PERSIST用于全局变量
MySQL 8.0使持久化全局动态服务器变量成为可能。许多服务器变量都是GLOBAL和DYNAMIC，可以在服务器运行时重新配置。例如：SET GLOBAL sql_mode='STRICT_TRANS_TABLES'; 但是，重新启动服务器时会丢失这些设置。
这项工作使得写入成为可能SET PERSIST sql_mode='STRICT_TRANS_TABLES'; 的结果是，该设置将在服务器重新启动后存活。该功能有许多使用场景，但最重要的是，它提供了一种管理服务器设置的方法，当编辑配置文件不方便或不可选时。例如，在某些托管环境中，您不具有文件系统访问权限，您拥有的只是能够连接到一台或多台服务器。至于SET GLOBAL你需要超级特权SET PERSIST。
还有RESET PERSIST命令。该RESET PERSIST命令具有从持久配置中除去配置变量的语义，从而将其转换为具有与之类似的行为SET GLOBAL。
MySQL 8.0允许SET PERSIST设置大多数只读变量，新值将在下次服务器重启时生效。请注意，只有一小部分只读变量是故意不可设置的。在这里可以看到Satish Bharathy的博客文章。
远程管理
MySQL 8.0实现了一个SQL RESTART命令。目的是通过SQL连接启用MySQL服务器的远程管理，例如通过SET PERSIST后面的a 来设置非动态配置变量RESTART。查看博客文章 MySQL 8.0：轻松更改配置和云端友好！ 由FrédéricDescamps提供。
重命名表空间（SQL DDL）
MySQL 8.0实现ALTER TABLESPACE s1 RENAME TO s2;共享/常规表空间是一个用户可见的实体，用户可以通过该实体创建，修改和删除。请参阅错误＃26949，错误＃32497和错误＃58006。
重命名列（SQL DDL）
MySQL 8.0实现ALTER TABLE ... RENAME COLUMN old_name TO new_name;这是对现有语法ALTER TABLE <table_name> CHANGE ...的改进，它需要重新指定列的所有属性。旧的/现有的语法的缺点是所有的列信息可能无法用于尝试重命名的应用程序。旧/现有语法中的意外数据类型更改也有可能导致数据丢失的风险。
安全功能
新的默认身份验证插件
MySQL 8.0将默认身份验证插件从mysql_native_password更改为caching_sha2_password。相应地，libmysqlclient也会使用caching_sha2_password作为默认的认证机制。新的caching_sha2_password结合了更高的安全性（SHA2算法）和高性能（缓存）。总的方向是我们建议所有用户在他们的所有网络通信中使用TLS / SSL。在这里可以看到Harin Vadodaria的博客文章。
Community Edition中的默认OpenSSL
MySQL 8.0在OpenSSL上统一为MySQL企业版和MySQL社区版的默认TLS / SSL库。以前，MySQL社区版使用YaSSL。在MySQL Community Edition中支持OpenSSL一直是最常用的功能之一。见弗雷德里克DESCAMPS博客文章在这里。
OpenSSL是动态链接的
MySQL 8.0与OpenSSL动态链接。从MySQL Repository用户的角度来看，MySQL包依赖于Linux系统提供的OpenSSL文件。通过动态链接，可以在不需要MySQL升级或补丁的情况下应用OpenSSL更新。见弗雷德里克DESCAMPS博客文章在这里。
撤消和重做日志的加密
MySQL 8.0实现了UNDO和REDO日志的静态数据加密。在5.7中，我们引入了存储在每个表文件表空间中的InnoDB表的表空间加密。此功能为物理表空间数据文件提供静态加密。在8.0中，我们将其扩展为包括UNDO和REDO日志。在这里看到文档。
SQL角色
MySQL 8.0实现SQL角色。角色是指定的特权集合。目的是简化用户访问权限管理。可以为用户授予角色，授予角色权限，创建角色，删除角色以及决定会话期间适用的角色。见弗雷德里克DESCAMPS博客文章在这里。
允许授予和撤销PUBLIC
MySQL 8.0引入了配置变量mandatory-roles，可以在创建新用户时用于自动分配和授予默认角色。例如：。所有指定的角色总是被视为授予每个用户，他们不能被撤销。除非将这些角色设为默认角色，否则这些角色仍需要激活。当新服务器配置变量设置为“ON”时，所有授权角色始终在用户通过身份验证后激活。role1@%,role2,role3,role4@localhostactivate-all-roles-on-login
打破超级特权
MySQL 8.0为以前版本中使用的SUPER的各个方面定义了一组新的粒度特权。目的是限制用户对手头工作所需要的访问权限，仅此而已。例如BINLOG_ADMIN，CONNECTION_ADMIN和ROLE_ADMIN。
管理XA事务的授权模型
MySQL 8.0引入了一个新的系统特权XA_RECOVER_ADMIN来控制执行语句的能力XA RECOVER。XA RECOVER未被授予新系统特权的用户所做的尝试XA_RECOVER_ADMIN将导致错误。
密码轮换政策
MySQL 8.0引入了密码重用的限制。可以在全局级别以及单个用户级别配置限制。密码历史保持安全，因为它可能会提供有关个人用户更改密码时使用的习惯或模式的线索。该密码轮换政策来除了其他现有机制，如密码过期策略和允许的密码策略。请参阅密码管理。
减缓用户密码的暴力攻击
基于连续不成功的登录尝试，MySQL 8.0在认证过程中引入了延迟。目的是减缓对用户密码的暴力攻击。可以配置延迟引入之前的连续不成功尝试的次数，以及引入的最大延迟量。
退休跳过授予表
服务器启动时，MySQL 8.0不允许远程连接–skip-grant-tables。参见Omar Bourja报告的Bug＃ 79027。
将mysqld_safe功能添加到服务器
MySQL 8.0实现了当前在mysqld_safe服务器内脚本中找到的部分逻辑。这些工作提高了服务器的可用性，例如在使用--daemonize启动选项时。这项工作还使用户对mysqld_safe script我们希望在未来消除的依赖性减少。它还修复了Peter Laursen报告的Bug＃75343。
性能
MySQL 8.0具有更好的读/写工作负载，IO绑定工作负载和高争用“热点”工作负载的性能。此外，新的资源组功能为用户提供了一个选项，可以通过将用户线程映射到CPU来针对特定硬件上的特定工作负载进行优化。
扩展读/写工作负载
MySQL 8.0在RW和繁重的写入工作负载上可以很好地扩展。在密集RW工作负载上，我们观察到来自4个并发用户的性能更好，与MySQL 5.7相比，在高负载情况下性能提高了2倍以上。我们可以说，虽然5.7只读工作负载的可伸缩性显着提高，但8.0显着提高了读/写工作负载的可伸缩性。其效果是MySQL提高了标准服务器端硬件（如带有2个CPU插槽的系统）的硬件利用率（效率）。这种改进是由于重新设计InnoDB如何写入REDO日志。与用户线程不断努力记录其数据更改的历史实现相比，在新的REDO日志解决方案中，用户线程现在是无锁的，REDO写入和刷新由专用后台线程管理，整个REDO处理变为事件驱动。请参阅Dimitri Kravtchuk的博客文章这里。
利用IO容量（快速存储）
MySQL 8.0允许用户使用每个存储设备的全部功能。例如，使用英特尔Optane闪存设备进行测试，我们能够在完全IO界限工作负载下超出1M点选QPS。（IO界限意味着数据不缓存在缓冲池中，但必须从辅助存储中检索）。这种改进是由于摆脱了 fil_system_mutex全局锁定。
高竞争负载下性能更佳（“热门行”）
MySQL 8.0显着提高了高争用工作负载的性能。当多个事务正在等待表中同一行上的锁定时，会发生较高的争用工作负载，从而导致等待事务队列。许多真实世界的工作量在一天中并不平滑，但可能会在特定时间爆发（帕累托分布式）。无论是在每秒事务处理时间，平均延迟时间和第95百分位延迟方面，MySQL 8.0的处理都要好得多。由于系统需要较少的备用容量，因此可以以较高的平均负载运行，因此对最终用户的好处是更好的硬件利用率（效率）。最初的补丁由Jiamin Huang提供（Bug＃84266）。请研究Contention-Aware事务调度（CATS）算法，并在此处阅读Jiamin Huang和Sunny Bains撰写的MySQL博客文章。
资源组
MySQL 8.0引入了全球资源组到MySQL。通过资源组，DevOps / DBA可以管理用户/系统线程和CPU之间的映射。这可用于跨CPU分割工作负载，以在某些使用情况下获得更高的效率和/或性能。因此，资源组向DBA工具箱添加了一个工具，该工具可以帮助DBA增加硬件利用率或提高查询稳定性。例如，通过在英特尔（R）至强®CPU E7-4860 2.27 GHz 40核心-HT盒上运行的Sysbench RW工作负载，通过将写入负载限制为10个内核，我们使整体吞吐量翻了一番。资源组是一个相当先进的工具，需要熟练的DevOps / DBA才能有效使用，因为效果会随着负载类型和手头硬件而变化。
其他特性
更好的默认值
在MySQL团队中，我们密切关注MySQL的默认配置，旨在为用户提供最佳的现成体验。MySQL 8.0将30多个默认值更改为我们认为更好的值。请参阅博客文章MySQL 8.0中的New Defaults。Mogan Tocker 在博客文章中概述了这一动机。
协议
MySQL 8.0添加了一个选项来关闭结果集的元数据生成和传输。构造/解析和发送/接收结果集元数据会消耗服务器，客户端和网络资源。在某些情况下，元数据大小可能比实际结果数据大小大得多，元数据不需要。我们可以通过完全禁用这些数据的生成和存储来显着加快查询结果传输速度。客户可以设置CLIENT_OPTIONAL_RESULTSET_METADATA标志，如果他们不希望元数据返回结果集。
C客户端API
MySQL 8.0通过一个稳定的接口扩展了libmysql的C API，以便从服务器获取作为数据包流的复制事件。目的是为了避免必须调用未记录的API并打包内部头文件以实现基于binlog的程序，例如Hadoop的MySQL Applier。
Memcached的
MySQL 8.0通过多个获取操作并支持范围查询来增强InnoDB Memcached功能。我们添加了对多重get操作的支持，以进一步提高读取性能，即用户可以在单个memcached查询中获取多个键值对。Yoshinori @ Facebook已经要求支持范围查询。通过范围查询，用户可以指定特定的范围，并获取该范围内的所有合格值。这两个功能都可以显着减少客户端和服务器之间往返的次数。
持久的自动计数器
MySQL 8.0 AUTOINC通过将计数器写入重做日志来保留计数器。这是一个很老的Bug＃199的修复程序。MySQL恢复过程将重播重做日志并确保AUTOINC计数器的值正确。不会有任何AUTOINC计数器回滚。这意味着数据库恢复将在崩溃后重新建立最新的已知计数器值。它带有保证AUTOINC计数器不能获得两次相同的值。计数器单调递增，但请注意可能存在空位（未使用的值）。缺乏持久性AUTOINC在过去被视为麻烦，例如，参见Stephen Dewey在2006年或本博客文章中报告的Bug＃21641。
参考：https://www.oschina.net/news/95325/mysql-8-0-ga-released?appinstall=0
http://www.sdbeta.com/wg/2018/0420/222014.html
转载自：https://blog.csdn.net/zwj1030711290/article/details/80025981