我们已经为生成的列(WL#8170)实现了一个表达式分析器。这样做可以让我们的排序和参考优化器有机会使用已经为生成的列定义的索引。关于这个功能的一个案例是在 JSON 文档上产生和自动使用索引。
我们已经在 SQL 查询(WL#8607)中加上了内联 JSON 路径表达式。MySQL 现在这样执行查询：SELECT … FROM t1 WHERE t1.json_field->”$.path.to[0].key”= 123;
生成的列&可生成索引的虚拟化列
我们第一次实现生成的列(WL#411, WL#8114)。每列的值，不像一个有规律的字段的值，没有通过用户设置而是当行创建或者更新时通过服务器使用用户定义表时定义的特殊的表达式计算。生成的列也可以被物化（被存储）或者非物化（虚拟）。关于这方面的内容可以看看 Evgeny Potemkin 的文章“在MySQL 5.7.5中的生成列“。
然后我们在非物化虚拟列上为二级索引的创建提供了支持，以及这些索引在快速检索计算值和搜索方面的使用(( ) 。
非物化虚拟列是用来处理在真正的 InnoDB 索引记录中不存在时，但是他们的元数据在 InnoDB 系统表和元数据缓存中注册了的情况，虚拟列为表提供了灵活性和保存空间，还有较重要的一点，添加/删除这样的列而不用重新构建表。这样做是存储和处理非关系型数据如 JSON 最好的选择。然而，由于这些列不是物化的，因此扫描和检索比一般的列（物化的列）要慢一些，但是，虚拟列的值在二级索引里物化了，因此这些列的数据还是比较容易进行检索和处理的。因此这也极大的提高了虚拟列的实际值。通过这样的方式，在一个虚拟生成的列上创建索引也变成了在线操作.
性能&可伸缩性
从社区反馈，账户追踪和在计算机硬件开发及本身架构方面了解到， 对 MySql 来说性能和可伸缩性是最重要的部分。迄今为止，在 MySql5.7 中， 我们已经在 InnoDB 实现了对只读（RO）结果的可伸缩性处理和在服务层明显的提高了连接速度的处理。我们也在 InnoDB 上的可伸缩性读写，提高内部操作（快速稳定的刷新/清除），和快速批量数据加载方面有了很好的进展。
InnoDB 的可伸缩性只读。我们已经提高了只读和多数读取工作负载的性能。我们也已经极大的提高InnoDB 处理只读事务(WL#6047, WL#6899, WL#6906, WL#6578)。我们也去掉了服务层连接与元数据锁定(MDL) 有关的部分和 InnoDB 中 THR_LOCK 锁的使用(WL#7304, WL#7305, WL#7306, WL#6671)。在 WL#6671 之后的一些工作负载中，LOCK_grant 锁就在未来可伸缩性的瓶颈方面清晰了很多； 例如，单张表 InnoDB POINT_SELECT Sysbench 的测试（见 Bug#72829）。目前这个问题已经通过分割 LOCK_grant 锁解决了（见WL#8355）。最终，我们也在涉及到基于内存的临时表创建的工作负载方面突破了 LOCK_plugin 和 THR_LOCK_lock 锁的瓶颈；例如，InnoDB 中像 Sysbench 的 SELECT_DISTINCT 的测试。但是，我们不应该为内部临时表获得这些锁，因此，我们清除了这些不必要的开销（见WL#8356）。也可以看一下 Dimitri Kravtchuk 的文章“MySQL 性能: MySQL 5.7 达到 500K QPS “，“MySQL 5.7 : 使用 InnoDB 缓存插件超过 1M QPS“，Sunny Bains 的文章“MySQL5.7.3对事务生命周期的改进“，和 Jimmy Yang 的文章”MySQL 5.7.3: 深入了解使用 InnoDB缓存达到 1百万QPS “。
InnoDB 读写扩展。改善了数据库的读写负载性能。移除了 InnoDB 的索引死锁(WL#6363, WL#6326)。现在的索引锁被替换成更加精细的树的“块锁”，然而以前常常用它来保护整个的索引树结构。可以参考 Yasufumi Kinoshita 的文章“MySQL-5.7 improves DML oriented workloads（MySQL-5.7 改善了面向数据操作语言的工作负载）”。