MySQL InnoDB存储引擎更新Cardinality统计信息的策略分析

这篇文章主要讲解了“MySQL InnoDB存储引擎更新Cardinality统计信息的策略分析”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“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信息。

感谢各位的阅读，以上就是“MySQL InnoDB存储引擎更新Cardinality统计信息的策略分析”的内容了，经过本文的学习后，相信大家对MySQL InnoDB存储引擎更新Cardinality统计信息的策略分析这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！