接着上期的说，MYSQL 8 不光在配置参数上和MYSQL 5.7 渐行渐远，（例如数据文件存储方式，原子性，等等），下面还的继续说 INNODB storage engine，其实MYSQL 8 在启用一个新的存储引擎1 在MYSQL 5.7 临时表包含了一个 "converting HEAP to on disk", 意思当临时表达到最大的内存使用的限制（一个表一个）16MB，则系统就要将这个临时表放到磁盘上了，但MYSQL 8.0 将这个默认的临时表的设置变成1GB2 支持争用事务调度，大致的意思是在数据库中的事务如果阻塞是会对其进行判断的，例如一个事务已经锁定的OBJECTS 相对于另一个事务来对比要多，那他在优先级上会变得更高，系统会根据优先级来判断应该让那个事务优先执行，来降低延迟提高吞吐量。3 在MYSQL 5.7及之前的版本是没有直方图的，MYSQL 8 开始加入直方图，让语句查询中优化只有索引这个选择之外可以进行直方图的优化选择，索引虽然好，但是会影响 UPDATE ,INSERT DELETE等性能问题，所以通过建立（手动）直方图的方法也可以优化查询，加速查询的速度（之前有一期是分析或这个的，但看上去不是太美）4 资源池的概念，资源池是可以认为是来分配CPU 的方式，来提高，或降低这个在CPU 资源上的获取的。（SQL SERVER 也有类似的功能，从 2008 起就有，但实际上使用的人并不是很多），下面是一个例子（我估计使用的人也不会特别多，语法也和ORACLE 越来越接近了，以后是不是要叫 大 ORACLE ， 小ORALCE）5 sys 库，（这个就不多说了，和ORACLE 某些特性接近，好处是获得系统的统计信息，监控信息越来越容易了）6 在MYSQL中设置变量的时候，例如set innodb_buffer_pool_size = 96G ; 这样的语句你可能会怕，在执行完后，下次重启如果MY,CNF 没有改变的话，就糟糕了, MYSQL 8.O 提供了Set persist 命令 （之前也有一期讲过的，很好用）。降低了临时设置参数后来忘记改MY,CNF 的烦恼。7 MYSQL SHELL 的更新，以后MYSQL的管理人员，如果想继续更好的使用MYSQL ，（官版）会建议使用MYSQL SHELL 来进行MYSQL 的操作，当然你可以使用SQL ，PYTHON ，JAVASCRIPT 等语言来控制MYSQL, 其背后深层次的原因是MYSQL 将不再是一个传统的数据产品，他将集合大文档存储，JSON 存储处理，等等工作，甚至可能会进入数据分析领域。所以ORACLE 在这方面还是蛮下功夫的。当然可能以后的MYSQL 的安装文件也会从几十MB ，几百MB ，迈向 GB 或者几个GB ，所以未来叫小ORACLE 也有蛮贴切的。8 整体向复杂查询迈进，之前一直被别的数据库嘲笑的不能进行复杂的查询例如 窗口函数，比较差劲的count的性能，row_number 函数 等等，这都意味着，MYSQL 8.0 本身处理SQL 语句的能力将变得越来越强，和其他三个数据库越来越接近，单库的处理语句能的力也会越来越高。9 到了MYSQL 8.0 估计也不会在有人用什么 MHA 了，在复制方面会全面转向 MGR ，group replication, 等等，在MYSQL 5.7 （我用的是 5.7.23 MGR 使用一年的时间里面，刨除其他原因，MGR 仅仅有两次问题，导致集群散架），所以整体的MYSQL 高可用方案会变得越来越统一（和ORACLE 一样，要不 DG AGD ,要不 RAC）10 最新的数据CLONE 功能，这是一位葡萄牙工程师的作品，其主要的作用还是弥补在MGR 某个服务器失败后的节点恢复，这点MONGODB 做的很好，如果某个节点失效的情况下，是很容易进行节点的恢复和添加的，所以MYSQL 为了以后大力推行 MGR ，这点工作也是要做的，以后节点失败在重做将不是一件很难的事情。通过对MYSQL8的一些粗浅的新的功能点的学习，以下得出一些不成熟的感性理解1 MYSQL 将不是单库性能差的代言者，同时ORACLE 是准备将MYSQL 从互联网的使用环境中，拉出来放到参与复杂SQL 计算的数据库阵营里面，目前就开源产品中流行的数据库中POSTGRESQL 在这一个领域是 NO.12 数据库高可用将从多种方式，变为MGR 为主导的分布式高可用模式3 从轻型数据要转变，变的越来越重，功能越来越多从MYSQL 5.5 --5.6 --5.7 如果说还有似曾相识的影子以及功能性的叠加修补，到了MYSQL 8 这一代，的确是和之前的MYSQL 已经拉开了距离，看上去越来越像传统数据库，什么都要有的范。（所以为什么有公司在使用MYSQL上 点名要使用 MariaDB 可能也有自己的想法）