|
由于8.0内有很多C++11特性。需要gcc4.8版本以上。Rhel6系列默认gcc是4.7。在安装gcc6.1之后仍然检查不过。 原因可能是6.1版本不一定高于4.7，暂不讨论。鉴于升级gcc耗时较长，与测试目的不符。暂用官方rpm包安装。以便达到快速测试目的。 以下新功能介绍中，跟日常工作强相关大都经过测试。时间有限，未能面面俱到，有兴趣自行测试。 以下大部分来源自。其中部分以此引申出来。测试版本为MySQL8.0.11 GA版。 除了sha256_password认证插件。可用一种新的caching_sha2_password认证插件。后者可以使用缓存解决连接时的延时问题。 它还支持更多的连接协议，并且不需要与基于RSA密钥对的密码交换功能的OpenSSL进行链接。
对比可以看出。MySQL8.0中默认新建用户使用caching_sha2_password，而不是原生的加密策略。这样客户端使用原有方式连接就会出现问题。
这是由于两边默认密码插件不匹配导致无法加解密的原因。有两种方法解决。一种是服务端降级加密方式，一种是客户端升级加密方式。 第一种方式以安全代价换便捷。第二种相反。我想服务端应该是有全局参数控制新建用户使用什么插件进行加密的。如下：
这样一来客户端就能常规方式连接。但是之前创建的用户依然会报那样的错。解决方法是alter 语句修改。
注意的一点5.6的set password 的方式已经彻底被淘汰。且password函数已经被删除。
默认配置启动。初始化启动后，使用生成的密码******不能做任何事，但是可以set命令。 由于密码强度之强，使得多数情况下的修改validate_password.policy参数。(这点伤透了我的心，以前是下划线“_”。有点面向对象的味道)
总结：也就是说加密方式改变导致帐号连接改变。亦可以通过默认恢复到先前方式。 MySQL以前有密码强度策略，过期时间。现在还维护有关密码历史记录的信息，从而限制重复使用以前的密码（社会工程学）。 存在mysql.password_history表中。也就是说如果是从老版本升级到8.0.3版本之上。需要同时升级这些系统表（废话）。
自增列方面。现在自增列计数器会在每次值修改时，将值写到REDO LOG中，并且在CHECKPOINT时写到存储引擎私有的系统表中。 这就消除了以往重启实例自增列不连续的问题（这也可能形成了一个新的竞争点（盖国强会上提问InnoDB开发者））。 Btree索引被损坏。InnoDB会向REDO LOG中写入一个损坏标志。同时也会CHECKPOINT时将内存中损坏页的数据记录到存储引擎私有的系统表中。 |
