MySQL InnoDB存儲引擎更新Cardinality統(tǒng)計信息的策略分析

這篇文章主要講解了“MySQL InnoDB存儲引擎更新Cardinality統(tǒng)計信息的策略分析”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“MySQL InnoDB存儲引擎更新Cardinality統(tǒng)計信息的策略分析”吧！

在InnoDB存儲引擎中，Cardinality統(tǒng)計信息的更新發(fā)生在兩個操作中：insert和update。
InnoDB存儲引擎內(nèi)部對更新Cardinality信息的策略為：持久化（PERSISTENT）與非持久化統(tǒng)計數(shù)據(jù)（TRANSIENT）。
持久化（PERSISTENT）統(tǒng)計數(shù)據(jù)，存儲在mysql.innodb_index_stats和mysql.innodb_table_stats中。
非持久化（TRANSIENT）統(tǒng)計數(shù)據(jù)，存儲在information_schema.statistics和information_schema.tables中。
前者是innodb表后者是memory表，他們受參數(shù)innodb_stats_persistent的控制。從MySQL 5.6.6開始，默認(rèn)情況下，innodb_stats_persistent默認(rèn)為ON，優(yōu)化器統(tǒng)計信息會保留在磁盤上。
對于持久化（persistent）統(tǒng)計數(shù)據(jù)策略：
表中1/10的數(shù)據(jù)已發(fā)生變化時，且設(shè)置了innodb_stats_auto_recalc和innodb_stats_persistent，則通過persistent方式更新統(tǒng)計信息。
兩次申請統(tǒng)計數(shù)據(jù)收集要超過10S。
在5.6中，引入的一個新參數(shù)innodb_stats_auto_recalc用于控制是否進(jìn)行自動統(tǒng)計信息計算。當(dāng)表上的記錄修改超過10%時，就會對統(tǒng)計信息重新計算;這只對在建表時打開了innodb_stats_persistent或者指定了建表選項STATS_PERSISTEND=1生效，采樣page的個數(shù)通過參數(shù)innodb_stats_persistent_sample_pages來控制(實際讀取的page數(shù)會大于該值)。
innodb_stats_auto_recalc 這個參數(shù)控制著在表中行的數(shù)量改變超過10%的時候，是否重新收集統(tǒng)計信息。這個收集的動作是異步的，在執(zhí)行完大的dml后，可能會過一段時間才重新收集統(tǒng)計信息，如果想要及時的統(tǒng)計信息，執(zhí)行analyze命令去收集。
對于非持久化（transient）統(tǒng)計數(shù)據(jù)策略：
InnoDB檢測到自上次更新統(tǒng)計信息以來表的1/16已被修改，通過transient方式更新統(tǒng)計信息。
stat_modified_counter > 2000000000。
對于非持久化，第一種策略為自上次統(tǒng)計Cardinality信息后，表中1/16的數(shù)據(jù)已經(jīng)發(fā)生過變化，這時需要更新Cardinality信息。第二種情況考慮的是，如果對表中某一行數(shù)據(jù)頻繁地進(jìn)行更新操作，這時表中的數(shù)據(jù)實際并沒有增加，實際發(fā)生變化的還是這一行數(shù)據(jù)，則第一種更新策略就無法適用這種情況。故在InnoDB存儲引擎內(nèi)部有一個計數(shù)器stat_modified_counter，用來表示發(fā)生變化的次數(shù)。當(dāng)stat_modified_counter大于2000000000時，同樣需要更新Cardinality信息。

感謝各位的閱讀，以上就是“MySQL InnoDB存儲引擎更新Cardinality統(tǒng)計信息的策略分析”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對MySQL InnoDB存儲引擎更新Cardinality統(tǒng)計信息的策略分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！