我们都知道，如果where条件在字段上带了函数，那么就不能使用索引，并且不容易优化。幸运的是，MySQL 5.7有一个新特性——虚拟列，专门为此而设计。接下来，我们一起了解一下。

在MySQL 5.7中，支持两种Generated Column，即 Virtual Generated Column和Stored Generated Column 。Virtual Generated Column只保存在数据字典（表的元数据）中，而不会将这一列数据持久化到磁盘上；Stored Generated Column则会将Generated Column持久化到磁盘上，而不是每次读取的时候计算得到。很明显，Stored Generated Column需要更多的磁盘空间，因此并没有Virtual Column的优势。因此，在MySQL 5.7中，如果不指定Generated Column的类型，默认就是Virtual Column。

如果需要使用Stored Generated Column，可能在Virtual Generated Column上建立索引更加合适。因此，一般情况下都使用Virtual Generated Column，也就是MySQL默认的方式。

假设有一个包含一个日期类型列SimpleDate的表。SimpleDate是一个常用的查询字段，并需要对其执行日期函数。然而，即使对SimpleDate建立索引，也无法使用这个查询语句，因为日期函数阻止了索引。为了提高查询效率，通常需要新建一个字段SimpleDate_dayofweek，存放dayofweek(SimpleDate)的计算结果，然后对这列创建索引。SimpleDate_dayofweek的值需要通过程序写入，例如使用触发器，在SimpleDate有变动时更新。这样，查询就可以改为：SELECT * FROM myTable WHERE SimpleDate_dayofweek=3;。

这么做的好处是提高了查询性能，因为可以使用SimpleDate_dayofweek列的索引。不过，同时也带来了其他麻烦，例如需要程序维护SimpleDate_dayofweek这一列，而且这种计算方式可能并不适用于所有查询场景。

虚拟列Generated Columns就是用来解决这个问题的。它可以增加一个可被索引的列，但实际上并不存在于数据表中。下面用一个实验来说明这个问题：

需求：为了实现对json数据中部分数据的索引查询，考虑使用MySQL 5.7中的虚拟列功能。

1.创建表

2.准备数据

3.构建姓名的虚拟列

4.构建索引

5.测试是否使用索引。可以看出已经使用了索引。

6.插入新数据。此时，表的结构已经多出了user_name这一虚拟列。在插入新数据时，需要特别注意不能给虚拟列插入数据。

做完实验后，我们可以比较一下加不加虚拟列时是否走索引，这样可能会更容易让大家理解。接下来我们还会分享更多devops和DBA相关的内容，感兴趣的朋友可以关注一下。