MySQL8。0的预研清单和计划

　　最近在团队内聊了下关于MySQL8。0的特性调研工作，其实线上已经稳定运行了近20的业务，但是很多思维模式和习惯还是继承自5。7，所以需要与时俱进，在技能上能够引导开发同学，在后端的支持上能够做到游刃有余。
　　当然对于MySQL8。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。MySQL5。5升级到8。0的建议和策略
　　这里着重需要交付的是跨大版本升级的路线图，包括可能潜在的问题和需要格外注意的事情。11。数据库参数的变化
　　参数的变化是最直接学习功能特性的方式12。窗口函数
　　窗口函数还是带有一些想象空间的，但是在复杂度方面有一丝的顾虑，否则用不好就是引狼入室13。密码插件，对于开发环境需要注意
　　大家一般在网上看到的升级到8。0最大的代沟就是密码插件变了，其实可以理解更深入一些。14。双密码
　　在安全管理和运维的支撑方面是一个很强大的功能，尤其对于哪些安全管控严格的公司，每隔一段时间需要更换密码，这种场景简直有如神助。15。资源管理
　　资源管理是一个需要入手的特性，能够在一定程度上使得管理更加主动可控。16。自增列的问题修复
　　自增列的使用其实是个伪命题，但是大家还很需要它，但是鲜有人知道自增列本身是有问题的，老大难的问题在8。0才修复。17。binlog加密
　　安全层面的，showbinarylogs已经发生了很大的变化。18。日志压缩
　　需要从多个维度进行压缩性价比的考量。19。redo归档
　　这是一个需要格外关注的特性，归档也就意味着redo可以更加灵活。20。新增mysql。innodbddllog
　　这个特性让我比较纠结，但是还是希望能够深入测试一下。21。派生表优化
　　优化器中的改进点，让人又爱又恨的派生表，至少还是有不小的改进空间的。22。表连接优化
　　连接层面的优化需要关注，比如HashJoin23。复制延迟优化
　　writeset的延迟优化改进很香，相关的使用和原理需要认真总结下。24。8。0的权限规则
　　8。0的权限体系引入了角色，同时管理模式已经和oracle很相似了。25。count优化
　　count的优化确实很明显，相比于Percona同版本，社区版本已经体现除了很大的优势。
　　26。克隆插件
　　克隆插件式运维层面来说一个关键的特性，期望值很高。