mysql 存储引擎 统计分析_MySQL InnoDB存储引擎更新Cardinality统计信息的策略介绍

在InnoDB存储引擎中，Cardinality统计信息的更新发生在两个操作中：insert和update。

InnoDB存储引擎内部对更新Cardinality信息的策略为：持久化(PERSISTENT)与非持久化统计数据(TRANSIENT)。

持久化(PERSISTENT)统计数据，存储在mysql.innodb_index_stats和mysql.innodb_table_stats中。

非持久化(TRANSIENT)统计数据，存储在information_schema.statistics和information_schema.tables中。

前者是innodb表后者是memory表，他们受参数innodb_stats_persistent的控制。从MySQL 5.6.6开始，默认情况下，innodb_stats_persistent默认为ON，优化器统计信息会保留在磁盘上。

对于持久化(persistent)统计数据策略：

表中1/10的数据已发生变化时，且设置了innodb_stats_auto_recalc和innodb_stats_persistent，则通过persistent方式更新统计信息。

两次申请统计数据收集要超过10S。

在5.6中，引入的一个新参数innodb_stats_auto_recalc用于控制是否进行自动统计信息计算。当表上的记录修改超过10%时，就会对统计信息重新计算;这只对在建表时打开了innodb_stats_persistent或者指定了建表选项STATS_PERSISTEND=1生效，采样page的个数通过参数innodb_stats_persistent_sample_pages来控制(实际读取的page数会大于该值)。

innodb_stats_auto_recalc 这个参数控制着在表中行的数量改变超过10%的时候，是否重新收集统计信息。这个收集的动作是异步的，在执行完大的dml后，可能会过一段时间才重新收集统计信息，如果想要及时的统计信息，执行analyze命令去收集。

对于非持久化(transient)统计数据策略：

InnoDB检测到自上次更新统计信息以来表的1/16已被修改，通过transient方式更新统计信息。

stat_modified_counter > 2000000000。

对于非持久化，第一种策略为自上次统计Cardinality信息后，表中1/16的数据已经发生过变化，这时需要更新Cardinality信息。第二种情况考虑的是，如果对表中某一行数据频繁地进行更新操作，这时表中的数据实际并没有增加，实际发生变化的还是这一行数据，则第一种更新策略就无法适用这种情况。故在InnoDB存储引擎内部有一个计数器stat_modified_counter，用来表示发生变化的次数。当stat_modified_counter大于2000000000时，同样需要更新Cardinality信息。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15498/viewspace-2156325/，如需转载，请注明出处，否则将追究法律责任。