如果须要Stored Generated Golumn的话，可能在Virtual Generated Column上建立索引更加得当。综上，一样平常情形下，都利用Virtual Generated Column，这也是MySQL默认的办法
语法<type> [ GENERATED ALWAYS ] AS ( <expression> ) [ VIRTUAL|STORED ][ UNIQUE [KEY] ] [ [PRIMARY] KEY ] [ NOT NULL ] [ COMMENT <text> ]运用处景
假设有一个表，个中包含一个 date 类型的列 `SimpleDate` date
SimpleDate 是一个常用的查询字段，并须要对其实行日期函数，例如
SELECT ... WHERE dayofweek(SimpleDate) = 3 ...
此时的问题是 纵然对 SimpleDate 建立索引，这个查询语句也无法利用，由于日期函数阻挡了索引。
为了提高查询效率，常日要进行额外的操作，例如新建一个字段 SimpleDate_dayofweek，存放 dayofweek(SimpleDate) 的打算结果，然后对这列创建索引，SimpleDate_dayofweek 的值须要程序写入，例如利用触发器，在 SimpleDate 有变动时更新这样查询就可以改为
SELECT ... WHERE SimpleDate_dayofweek = 3 ...
这么做的好处是提高了查询性能，可以利用 SimpleDate_dayofweek 列的索引了，但又带来了其他麻烦，例如
降落了数据写入性能增加冗余数据，占用了更多的存储空间增加代码掩护本钱虚拟列 Generated Columns 便是用来办理这个问题的，可以增加一个可被索引的列，但实际上并不存在于数据表中，下面用一个实验来解释下：
实验需求：为了实现对json数据中部分数据的索引查询，考虑用MySQL5.7中的虚拟列功能
1、创建表
create table user(uid int auto_increment,data json,primary key(uid));
2、准备数据
insert into user values (NULL,'{\"大众name\"大众:\公众hwb\公众,\"大众address\"大众:\"大众guangzhou\"大众}');insert into user values (NULL,'{\"大众name\"大众:\"大众tqy\公众,\公众address\"大众:\公众shenzhen\公众}');commit;
3、构建姓名的虚拟列
alter table user add user_name varchar(20) generated always as (data->'$.name');
4、构建索引
alter table user add index idx_name(user_name);
5、测试是否用到索引
explain select from user where user_name='\"大众hwb\"大众' \G;
可以看出用了索引了
6、插入新数据
此时的表的构造由于多出了user_name这一虚拟列，再插入别的数据要把稳在表后指明插入列（不能给虚拟列插入数据）
insert into user(uid,data) values (NULL,'{\"大众name\"大众:\"大众test\"大众,\"大众address\"大众:\"大众shantou\"大众}');
做完创造这个实验彷佛不是那么好理解...该当比拟一下加不加虚拟列有没走索引，可能会更随意马虎让大家理解的...后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~
