1: INNODB_SYS_VIRTUAL

表存储的是INNODB表的虚拟列的信息，当然这个还是比较简单的，我们直接通过SHOW CREATE TABLE 或者DESC TABLE就能看得到。

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

如果需要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> ]

例子：

create table user(uid int auto_increment,data json,primary key(uid));

insert into user values (NULL,‘{"name":"wang","address":"shenyang"}‘); insert into user values (NULL,‘{"name":"zhao","address":"riben"}‘);

alter table user add user_name varchar(20) generated always as (data->‘$.name‘);

不过虚拟列还是要加上索引的。

2：INNODB_SYS_INDEXES

提供相关INNODB表的索引的相关信息，和SYS_INDEXES 这个表存储的信息基本是一样的，只不过后者提供的是所有存储引擎的索引信息，后者只提供INNODB表的索引信息。

看一下官方文档的解释：

3： INNODB_METRICS

提供INNODB的各种的性能指数，是对INFORMATION_SCHEMA的补充，收集的是MySQL的系统统计信息。这些统计信息都是可以手动配置打开还是关闭的。有以下参数都是可以控制的：

innodb_monitor_enable, innodb_monitor_disable, innodb_monitor_reset, innodb_monitor_reset_all,

这些都是mysql的启动参数，给个启动例子：

--innodb_monitor_enable=[counter|module|pattern|all]

3： INNODB_TEMP_TABLE_INFO

存储的是INNODB的关于元数据的相关信息，如果要优化临时表的信息的时候就要用到这个表的信息INNODB_TEMP_TABLE_INFO，这个表惠记录所有的INNODB的所有用户使用到的信息，但是只能记录在内存中和没有持久化的信息。看一下官方的解释

4：INNODB_BUFFER_PAGE

这个表就比较屌了，存的是buffer里面缓冲的页数据。查询这个表会对性能产生很严重的影响，千万不要再我们自己的生产库上面执行这个语句，除非你能接受服务短暂的停顿。看一下官方的揭示

MySQL的内部机制是很奇怪的，当表，表数据，索引被删除的时候，其实并不会立即删除，而是保存再buffer pool里面，直到这些空间被别的新数据等需要的时候，才会被从buffer pool里面抹除。

5： INNODB_BUFFER_PAGE_LRU

这个表和的所有列是一样的，除了用LRU_POSITION 代替了BLOCK_ID 。首先我们要了解一下LRU是个什么东西。

MySQL的InnoDB引擎设置有索引及数据缓存池，其中用到的LRU算法来维持缓存的命中率

这里用到了顺序表list来作为缓冲池，每个数据节点称为block

该算法采用“中点插入法”：当插入一个新block时，移除表尾最近最少使用的block，在中点插入新block。

这个中点将链表分为两部分：

1.靠近表头的一部分，为young区，这里的block是最近使用的节点

2.靠近表尾的一部分，为old区，这里的block是最近少使用的

该算法通过链表中的block的使用热度来维持各block的位置，其中old区的block为链表满的时候移除的候选区

具体算法如下：

1.链表的3/8被设置为old区

2.中点不是链表的中间点，而是old区的表头节点，即old区与young区的相邻的那个节点

3.当读取的数据不在缓冲池里的时候，读取到的block需要插入到链表中，插入点为中点，但是插入的新节点为old区的节点，如果此时old区满了得话，移除表尾的block（LRU节点）

4.当读取old区的block时，该节点将变成“young”节点：此节点移动到young区的表头（young区的头部那里）

5.在数据库操作中，被访问的节点将移除到young的表头，这样一来，在young区中的未被访问的节点将逐渐往表尾移动，当移动过中点，将变为old区的节点。而old区的节点若被访问到将变为young节点移动到表头，而old区中的为被访问的节点依旧往表尾移动，当表满时，表尾那个block将会被淘汰掉

6：INNODB_BUFFER_POOL_STATS

表提供有关INNODB 的buffer pool相关信息，和show engine innodb status提供的信息是相同的。buffer pool里的数据是young 还是 NOT young取决于是否将数据一到头部或者尾部。young数据会被保存更久的时间，而相反的，其他not young的数据就会被擦除当新数据被写入buffer pool里面的时候。

我们看得到PAGES_NOT_MADE_YOUNG这列的数值很大的时候说明buffer pool的命中率是很低的，这就说明系统的性能是可能有问题的，内存压力较大，可以适当调大buffer pool的大小。

要说明LRU那边解释的元文目录：http://www.cnblogs.com/iamsupercp/p/3682659.html

尊重原创。