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統計信息的策略分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！