以下内容采集自 2019年9月19日 San Francisco Oracle open 大会内容。主题 What’s New in MySQL Optimizer and Executor?
正文（部分内容来自于语音翻译）—————————————————————————————————
我们将开始讨论从去年开始的MYSQL 8的新功能，以及相关的改进, 首先第一个议题是 MYSQL 8.0 : One Giant Leap for SQL ,下面展示了一个图片，对比MYSQL 8 和其他数据库对比，并在看板上明确的告知MYSQL 8.0 已经完全支持 SQL-92的两个功能 windows funciton 和 common table expressions CTE
图片截取的不是很清晰（其实我看着也费劲），其中对比的熟即可有 DB2 MariaDB MYSQL ORACLE Postgresql SQL SERVER SQLite 等
从对比中看，MariaDB 对比 MYSQL 全线崩溃， MYSQL 对比 ORACLE 更胜一筹，对比 POSTGRESQL 奇虎相当， 对比SQL SERVER 更胜一筹，对比DB2 更胜一筹。
对比的项目有 windows function , CTE , JSON_TABLE , Grouping function , ame columns in from clause
对比中 ame columns in from clause 只有 POSTGRESQL 和 DB2 支持
MYSQL SQL SERVER 部分支持， Oracle 不支持
从图中展示的结果
JSON_TABLE POSTGRESQL 不支持， 从总分和颜色上看，MYSQL 是这里面最好的，其次是POSTGRESQL ，然后是ORACLE 和 DB2
最后是SQL SERVER。
下一幅图是 MYSQL 8 的新功能
CTE
WINDOWS FUNCTIONS
SKIP LOCKED NO WAIT
HASH JOIN (8.018 support)
Explain Analyze giving you the Actual plan (8.018)
部分改进来自于face book
讲解者继续提出MYSQL 8 recap 翻新了一些功能
1 支持了 UNICODE 9
2 UTF8MB4 是默认的character set 具体的名字叫 utf8mb4_0900_ai_ci
3 对多种collations 的支持 包含了20 的特殊语言支持包含对日文和 俄文的（未提中文）
4 对这些语言的性能方面的支持
讲解者继续，MYSQL 8 对 GIS SRS SRID IS VIEWS GEOHASH AND
GEOJSON 等都开始支持 （地理功能）
下一部分开始讲解， MYSQL中遇到的问题，例如 HOT ROW CONTENTION multiple worker threads accessing the same rows
（其实就是并发对行访问中的锁的问题）
其中提出MYSQL 8 可以针对不同的逻辑开始使用 SKIP LOCKED， NOWAIT 功能，这将解决某些业务中（例如订票，及相关类似业务中的并发问题）
接下来，演讲者提出 MYSQL 8 支持 JSON DATA TYPE
例如 create table t1(json_col JSON) 这样的写法，并采用新的方式来处理JSON 数据。
然后是介绍， MYSQL 的 index extensions : Invisible and Descending ,Skip scan 功能。SKIP SCAN 是 FACEBOOK 公司给出的补丁。
MYSQL 8 在Cost model 进行了改善， 增加了cost model 对已经在内存的数据和需要在磁盘中读取数据的统计，设置了成本的常量对于不同的存储技术方式，提供了直方图来优化列值的分布。
可以通过 Analyze table table_name update histogram on column with buckets 的方式来优化。（之前写过一篇直方图的文字）
继续是HINTS
这里演讲者一带而过，提出MYSQL 8 对语句的处理进行了整体的优化，上到单个语句，下到JOIN ，并且在MYSQL 8 可以抛弃 straight join keyword.(但后面跟上一句 I guess )
后面继续介绍CTES
windows functions
这里跳过 GIS （与地理有关的MYSQL 的东西，因为我不是太懂并且也不大感兴趣，处理GIS 相关的数据有更好的数据库可以承担此项功能）
下面直接跳到 OPTIMIZATION 优化，这里提到将 IN 和 EXISTS 变化为 SEMI-JOIN 的方式来处理 NOT IN AND NOT EXISTS 变化为 anti-semi-join 的方式来处理。
其中对于 ANTI-SEMI-JOIN 中提到 not exists 和 not in 将直接转换为 anti-semi-join 在查询在内部被重写为antijoin，它返回类中不匹配的每一行的一个实例
上面的占用的篇幅比较大， 然后剩下的比较少的时间给了 JSON 明显可感觉出来，MYSQL8 在解析和优化器上进行了大面积的修改，而JSON 部分本身其实还是处于一个初级的阶段，和其他的成熟的 JSON 处理的工具或数据库还是有一段距离，尤其与MONGODB 相比，在JSON 处理上毫无优势。
最后讲解了 HASH JOINS 明显感觉到讲解者的自信，在将这段的时候一直是面带微笑，其中一大段的话的意思是，NESTED LOOP 在处理两个或多表的JOIN 运算是有很大的缺陷的，经常会导致 CPU 很高效率很低，因为每次都会根据索引来分批读取数据进行处理，而HASH JOIN 将是改变这样不明智处理的改革方式，在其中一个表中对要比对的值进行HASH MAP 的建立，然后进行值的比对，如果你是开发则知道这样的比对会比较快，我们建议使用HASH JOIN 或强制HASH JOIN 因为我们已经将其添加到了 HITS中，来代替BNL （block NESTED LOOP）,当你使用MYSQL 8.018 处理类似事务的时候你会很惊喜这样的方式
最后是 explain analyze 因为之前的EXPLAIN 很难让人很清晰的理解执行计划并找到哪里是慢的关键，，EXLAIN ANALYZE 将解决这个问题
最后用了不到一分钟，将下面的图快速的过了一遍， 其中一句话是我们将非标准的事情都 removed 如下面这个图中提到的，（意思大概就是虽然曾经有一些可能在MYSQL 看来是好的，但是确实是很荒谬的）所以就要去掉。
完结
根据上面的这段，估计有些DEVELOPER 在使用MYSQL 8的时候，会出现一些问题，例如distinct 不在会那么随便，不符合SQL 标准还可以运行的事情不会再有这样的福利了，还有一些已经习惯 MYSQL 5.7 习惯的用法，优化的方法在MYSQL8 也可能会适得其反（因为这些习惯是不对的），在MYSQL 8 中要被剔除。
但MYSQL8 早早晚晚会替代现有的 MYSQL 5.6 5.7 ，2020年在MYSQL8成熟后，可能就有大批要吃螃蟹的，企业用户了，还是值得期待的！
