最近在团队内聊了下关于MySQL 8.0的特性调研工作，其实线上已经稳定运行了近20%的业务，但是很多思维模式和习惯还是继承自5.7，所以需要与时俱进，在技能上能够引导开发同学，在后端的支持上能够做到游刃有余。
当然对于MySQL 8.0，有很多同学还是带有意思疑问，这个版本稳定吗，适不适合生产环境，如何平滑的升级到新的版本中，对此我们的调研工作需要做细做深，每一个技术点上都需要一些测评数据和对比数据的支撑。
我们经过讨论，锁定了一部分的特性内容，主要是从开发的角度来进行考量，还有一些特性是从运维管理侧来入手，这样一来就会形成两个分享方向，面向开发特性和面向运维管理。
其中带“*”的特性部分是和开发侧密切相关的，需要着重测试。
*1.驱动版本兼容性，jdbc驱动的变更
驱动的版本依赖性是相对于升级来说最需要关注的事情了，不能忽悠开发说没有任何变化，变化还是有的，但是需要清晰的定义出来。*2.字符集和排序规则（collation）和使用建议
字符集的使用还是需要格外注意，尤其mb3和mb4的兼容情况。*3.数据类型和一些变化，还有一些额外的细节，比如int(11)不建议，字段默认值
*4.JSON类型，创建索引
在我的经验中，业务愿意从5.5升级到5.7的最大原因就是因为JSON类型，希望在8.0里面能够带给我们更多的惊喜。
*5.索引基础
对于业务侧来说，如何正确的理解索引的实现原理是最基础的需求，通常来说，对索引基础的理解是很多开发性能问题的根因。
*6.索引优化：降序索引，隐藏索引，多值索引，函数索引
索引优化的部分属于进阶内容，这部分的内容还是需要和开发共同携手，至少在落地层面还是尽可能从测试环境开始入手。*7.变更操作，字段变更，字段范围，哪些可以在线操作，基于5.5是否有改进
在线变更在8.0是一个亮点，基本的变更代价还是需要考虑的。8.备份恢复，整体的备份恢复的支撑能力
*9.高可用方面，从5.7升级到8.0有什么影响，目前已经有哪些业务使用，哪些方面需要特意说明
10.MySQL 5.5升级到8.0的建议和策略
这里着重需要交付的是跨大版本升级的路线图，包括可能潜在的问题和需要格外注意的事情。11.数据库参数的变化
参数的变化是最直接学习功能特性的方式12.窗口函数
窗口函数还是带有一些想象空间的，但是在复杂度方面有一丝的顾虑，否则用不好就是“引狼入室”*13.密码插件，对于开发环境需要注意
大家一般在网上看到的升级到8.0最大的代沟就是密码插件变了，其实可以理解更深入一些。14.双密码
在安全管理和运维的支撑方面是一个很强大的功能，尤其对于哪些安全管控严格的公司，每隔一段时间需要更换密码，这种场景简直有如神助。15.资源管理
资源管理是一个需要入手的特性，能够在一定程度上使得管理更加主动可控。*16.自增列的问题修复
自增列的使用其实是个伪命题，但是大家还很需要它，但是鲜有人知道自增列本身是有问题的，老大难的问题在8.0才修复。17.binlog加密
安全层面的，show binary logs已经发生了很大的变化。18.日志压缩
需要从多个维度进行压缩性价比的考量。19.redo归档
这是一个需要格外关注的特性，归档也就意味着redo可以更加灵活。20.新增mysql.innodb_ddl_log
这个特性让我比较纠结，但是还是希望能够深入测试一下。21.派生表优化
优化器中的改进点，让人又爱又恨的派生表，至少还是有不小的改进空间的。22.表连接优化
连接层面的优化需要关注，比如Hash Join*23.复制延迟优化
writeset的延迟优化改进很香，相关的使用和原理需要认真总结下。24.8.0的权限规则
8.0的权限体系引入了角色，同时管理模式已经和oracle很相似了。*25.count优化
count的优化确实很明显，相比于Percona同版本，社区版本已经体现除了很大的优势。
26.克隆插件
克隆插件式运维层面来说一个关键的特性，期望值很高。
