作者介绍
杨志洪，DBAplus社群联合发起人，新炬网络首席布道师。Oracle ACE、OCM、《Oracle核心技术》译者。数据管理专家，拥有十余年电信、银行、保险等大型行业核心系统Oracle数据库运维支持经验，掌握ITIL运维体系，擅长端到端性能优化、复杂问题处理。现主要从事数据架构、高可用及容灾咨询服务。
好吧，标题显然目前还只是个噱头，但负责MySQL Server Tuning的研发总监表示在接下来的版本会考虑放进去，应该不是8.0，可能是9.0。
10月18日晚上，MySQL 8.0优化器新特性交流会如期举办，DBAplus社群从众多报名者中精选了15人，在会上与MySQL研发总监Manyi Lu进行了面对面的深度交流。除了Manyi之外，到场嘉宾还包括：MySQL台湾技术顾问Ivan Tu、太平洋保险研发副总陆进、海通证券数据库专家王朝阳、携程DBA何根华、绿芯产品经理高峰.......还有一些互联网公司的兄弟就不一一列出了，大家围坐一个长方桌近距离交流，气氛和效果都非常好，达成了一次真正意义上的技术交流，而不像一般的培训只是以听为主。
关注“dbaplus”订阅号，回复“8.0”或点击本文末【阅读原文】即可下载本次交流会Manyi分享的PPT！
先上2张照片：
MySQL研发总监Manyi Lu
方桌会议
作为一位MySQL吃瓜群众，我主要记录了一些我感兴趣的内容，主干是Manyi的分享，少部分是现场嘉宾的交流速记。
为什么新版本叫MySQL 8.0？
其实Manyi在演讲的时候不时还会说成5.8，之所以叫8.0，有两个原因：
-
之前其实研发过一个6.0的版本，但没公布；
-
当前有些组件，比如MySQL Cluster已经发布过了7.4。
所以为了统一所有组件的版本，减少用户歧义，直接“升级”到了8.0版本，以后的大版本就会是8.0，9.0，10.0，当然，也会出一些小版本，比如8.0.1、8.0.2之类的。
MySQL企业版和社区版的主要区别在哪里？
目前来说，企业版和社区版的主要区别在四个方面（企业版有，而社区版没有，短时间内也不会有）：
-
备份/恢复效率
-
Enterprise Monitoring
-
Thread Pool（对大规模并发的互联网应用来说非常重要，MySQL研发也希望开源，不过policy不允许）
-
安全控制（类似于TDE/audit等）
MySQL企业版已经是个盈利部门，研发人员在近两年内从100多人扩张到300人左右，所以企业版功能要更完善、更安全（至少是意愿上）是合理的。对那些不想支付庞大的Oracle license，又想使用相对完善功能来说，是一个合理的选择。比如我们前期与某互联网金融公司交流，对方就明确一定是全部系统使用MySQL，而且是企业版本，而不是社区版（相对Oracle来说，license费用确实低了太多）。当然，社区版仍然会有许多拥趸，毕竟在license上是零成本。
选用MySQL有哪些注意事项？
最最最重要的说明，我认为是字符集。Manyi建议大家选择UTF8mb4 Collation500，现场大部分企业用的是mb3。
8.0以后，默认的存储引擎就变为InnoDB了，对一些以前使用MyISAM的用户来说，可能：
-
select count（*）可能会觉得性能下降；
-
大批量的insert会慢一些。
InnoDB的团队已经在着手优化了，成效要拭目以待。
参会嘉宾提了哪些期望的新特性
好吧，噱头的标题源于这里。其实是在交流会之前，我跟Manyi交流的时候提的，Manyi表示，这次来大陆，支持Hash Join是被问得最多的特性，后续版本一定会支持，不过应该不在8.0这个版本中，因为她觉得还有更重要的功能要解决。
其他嘉宾的期望呢？
-
太保的陆老师期望更加智能、更加强大。目前虽然企业版有Enterprise Monitoring，但是仍然不够，期望可以类似Oracle的AWR、ADDM功能。这个期望被重点认可；
-
微软的兄弟提出希望人工提示的加强，动态显示的加强。关于Hint，这个也是跟Oracle学的，每个版本都在增加更多的Hint，MySQL一直在努力；
-
绿芯半导体的兄弟提出，希望对PCIE闪存卡兼容性更强些。这个暂时还没法智能判断，因为Server层不知道哪些表的数据是在磁盘上，还是在SSD上，还是在内存里，可以通过hint来解决；
-
携程的兄弟希望支持多线程并发完成一个任务；
-
Oracle的一名SC提出希望内存加速和一致性。这个已经有了，大概10%左右的加速提升；
-
MySQL的哪个版本最稳定？作为MySQL研发来说，只能告诉你最新版本就是最好的版本，要不咱干嘛发布出来呢？
-
海通的朝阳兄弟提了个需求，什么时候可以支持flashback？MySQL官方没有研发计划，不过国内已经有开源团队在做这方面的研发了；
-
多名嘉宾提到Sharding，分布式数据访问。其实MySQL一直在努力，从MySQL Cluster，Febric（已经停止研发，该团队调去搞InnoDB了），到InnoDB Cluster，不断地在调整和优化。到底是要类似于MongoDB Sharding的傻瓜化呢，还是自由灵活些，要抉择的东西蛮多....
8.0要在1年以后才会GA，所以，如果你有什么新特性希望在8.0里出现，欢迎在本文留言区提出，社群会统一收集反馈给MySQL研发总监。
MySQL的对手是谁？
从研发的角度来说，显然是MongoDB无疑，JSON在5.7版本的支持，就是为了抢回被MongoDB掠夺过去的一些客户，在8.0上增加了更多的JSON函数。 对于LBS类应用来说，MongoDB支持的也不错，而在8.0中，GIS的增强也是一大亮点。
显然，Postgre暂时还没被列入其中。本月下旬PG在上海将有一次年度大会，使用者还是在逐渐增加的。
其实，SQL Server在年初已经支持Linux阵营，往后未必不是MySQL的一大对手。
MySQL为什么会有许多存储引擎？
MySQL公司最开始主要研发的是Server部分，而存储引擎则是由不同的公司开发，以插件的形式与Server结合使用，不同的存储引擎适合不同的应用场景。
不过，目前MySQL Server和InnoDB都已经被Oracle公司收为己有，所以后续会重点扶持InnoDB。虽然其他存储引擎仍然会以插件的形式存在，不过Oracle公司自然而然的会把MySQL Server和InnoDB视为一个整体，有些特性优化会下方到InnoDB层，而不是在Server层进行：比如Foreign key，Partition等。
中间有个比较棘手的问题是Handler API，一部分问题的性能瓶颈在于此，而它要支持不同的存储引擎，而且至今没有version的概念，所以重构起来比较困难。
关于 MySQL的Hint
MySQL为什么要学Oracle提供Hint？ 是Oracle优化器变得越来越烂，越来越不自信么？
当然是为客户的应用性能稳定性着想。数据库的优化器非常复杂，就算是远没有Oracle复杂的MySQL的成本模型也是一样，可能更新的成本模型将99.9%的功能和场景都性能提升了，而0.1%的场景性能会有下降/退化，那么Hint就派上用场了。
目前来说，下面一些场景是需要用到Hint的：
-
没有索引的列，MySQL是没有统计信息的，filter是大概多少完全没概念。比如性别，许多开发人员喜欢用int或者varchar的数据类型，而又不会建索引；
-
大量数据查询，开发者明确知道一定是从磁盘读，而不是从内存读取，而优化器是不知道的；
-
一些特定的join顺序。
关于Sharding
Sharding是个好东西，MySQL开源解决方案也很多，不过目前MySQL官方仍然还在改良中。
Oracle的Sharding
MySQL Cluster + ndb engine的Sharding其实不错，不过要求比较严格，因此应用范围比较窄。
Sharding实现有两种可选路径，一种是类似于MongoDB的Sharding方式，完全对应用透明；另一种是由开发人员来选择Sharding key，灵活度高，同时也意味着对开发人员的要求提高。
从性能上说，尽可能不做跨库访问，或者跨库事务。但对于金融业务来说，分布式事务似乎是必然的，所以分布式事务的优化也是接下来8.0的重点改进。
越来越向Oracle靠近的MySQL
尽管MySQL的研发可能没觉得，但8.0实现的大多功能确实是Oracle已经非常成熟的功能，比如：
-
invisible index，Oracle11g实现，对我们删除一些潜在冗余索引非常有用；
-
Descending index；
-
Common table expressions，Oracle9i实现，with语句；
-
Improved performance of scans，缓存；
-
JSON aggregation；
-
Hints。
还有一些将开发或者正在开发的特性：
-
成本模型改进：histogram；
-
SQL WINDOWING分析函数；
-
缓存执行计划；
-
sequence（当前的自增长类型，会发生宕机后出现重复数据）。
这些特性Oracle都有了，或者说是好的东西，大家都会相互借鉴吧。这样，Oracle DBA以后转MySQL会更加容易，或者说，MySQL DBA不久的将来会变得没这么值钱。
JSON是个什么鬼？
JSON的全称是JavaScript Object Notation，一种数据交换格式，跟XML类似，比XML小巧。JSON在MySQL的内部是以BLOB的形式存储的。
JSON其实就是KEY-VALUE存储数据，网上的示例：
var a ={"one"："一","two":"二","three":"三"}
MongoDB的文档数据结构叫BSON（Binary JSON）格式，示例：
db.COLLECTION_NAME.insert(document)；
>db.col.insert({title: 'Name',
description: '周小平',
TItle: '权贵网红',
Wechart: '我是周小平'
})
哪些场景用JSON比较合适呢？比如通过接口去调用天气情况，提供的API返回的都是JSON数据集合：{Location:上海，Date:2016年10月20日，Time:AM 10:00，AirQuality:优，temperature：24}。 比如高德地图的周边应用。
Oracle在5.7和8.0以及后续的版本中，都会大力加强JSON的支持，就是要夺回失地。5.7中有个亮眼的功能，通过虚拟列个JSON创建索引，类似Oracle里面的函数索引，避免查找数据的时候，到整改BLOB对象里去找。
MySQL研发的困惑
以往这种系统软件的研发，要比应用软件的研发远得多，细细交流下来，其实发现他们的困惑相差不大。
-
花了很长时间研发的一个核心功能/核心函数，居然不如一个很多时间研发的函数受欢迎！比如JSON Aggregation；
-
被追问到底哪个版本最稳定？当然是最新版本，一个版本的上线，不仅是研发人员，包括销售和服务支持者都有否决权；
-
为什么这么好的功能，比如Thread Pool不给大家免费使用？当然要看领导的决策了；
-
为什么这么多人盯着“没那么重要的”Hash Join？因为应用软件开发人员已经被Oracle惯得只会写烂SQL了，应用一致到MySQL就死了；
-
为什么日本使用者在呼吁开发日语collation的字符集，而中国的使用者不在乎？据现场的兄弟说因为通用字符集日本人无法比较出爹妈（片假名），而中文没有这个问题，而且中文顺序的敏感度低。
MySQL的高可用架构如何选择？
相信这是很多即将使用MySQL的新同学的问题。
这个问题，MySQL强烈推荐5.7已经发的innodb cluster，它包含三个部分：
-
MySQL Router(替代febric)
-
MySQL Shell
-
MySQL Group Replication
在9月份的旧金山OOW大会上，从MySQL3.2开始使用的开发者Frederic Descamps对其中的核心插件Group Replication做了分享（详细的PPT可以在这里看到：http://www.slideshare.net/lefred.descamps/mysql-innodb-cluster-group-replication）：
有多好用还有待来自真实环境的反馈吧。除此之外，DBAplus社群分享过几个常用的高可用架构：
MySQL的市场份额在增大么？
目前还没有准确数据，但受欢迎程度MySQL基本上稳坐老二的位置，和老三SQL Server一起甩开MongoDB和Postgre几条街，他们和更后面的几位在稍稍的蚕食着Oracle的分值（不是市场占有率）。
不过，据DB-engines 10月4日的文章，开源关系型数据库近半年来的受欢迎度在一个相对持平状态，不像之前一直处于上升的态势。
应该说，在MySQL越来越向Oracle靠近的过程中，传统行业的互联网业务（跟携程、微信、支付宝接口的业务、网上商城等）势必会越来越多的使用MySQL，而核心主营业务由于开发商的因素更换的可能性非常小。
本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-10-21
