这篇文章主要讲解了“MySQL InnoDB存储引擎更新Cardinality统计信息的策略分析”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“MySQL InnoDB存储引擎更新Cardinality统计信息的策略分析”吧!
创新互联建站-专业网站定制、快速模板网站建设、高性价比浏阳网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式浏阳网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖浏阳地区。费用合理售后完善,10多年实体公司更值得信赖。
在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统计信息的策略分析这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!