詳解mysql持久化統(tǒng)計(jì)信息

更新時(shí)間：2020年12月01日 11:31:21 作者：蔣樂(lè)興的技術(shù)隨筆

這篇文章主要介紹了mysql持久化統(tǒng)計(jì)信息的相關(guān)資料，幫助大家更好的理解和使用MySQL數(shù)據(jù)庫(kù)，感興趣的朋友可以了解下

一、持久化統(tǒng)計(jì)信息的意義：

　　統(tǒng)計(jì)信息用于指導(dǎo)mysql生成執(zhí)行計(jì)劃，執(zhí)行計(jì)劃的準(zhǔn)確與否直接影響到SQL的執(zhí)行效率；如果mysql一重啟

　　之前的統(tǒng)計(jì)信息就沒(méi)有了，那么當(dāng)SQL語(yǔ)句來(lái)臨時(shí)，那么mysql就要收集統(tǒng)計(jì)信息然后再生成SQL語(yǔ)句的執(zhí)行

　　計(jì)劃。如果能在關(guān)閉mysql的時(shí)候就把統(tǒng)計(jì)信息保存起來(lái)，那么在啟動(dòng)時(shí)就不要再收集一次了，這種處理方式

　　有助于效率的提升。

二、統(tǒng)計(jì)信息準(zhǔn)確與否也同樣重要：

　　第一目中我們說(shuō)明了“持久化統(tǒng)計(jì)信息的意義”，我們的假設(shè)統(tǒng)計(jì)信息是有用的，是準(zhǔn)確的；如果統(tǒng)計(jì)信息本身

　　已經(jīng)過(guò)時(shí)了，比如說(shuō)統(tǒng)計(jì)信息是在表中只有100行時(shí)統(tǒng)計(jì)出來(lái)的，這種情況下往往走全表掃描開(kāi)銷會(huì)更小，但是

　　呢！現(xiàn)在表中的行數(shù)已經(jīng)達(dá)到了100萬(wàn)行，明顯這種過(guò)時(shí)的統(tǒng)計(jì)信息會(huì)引發(fā)性能災(zāi)難，所以統(tǒng)計(jì)信息的時(shí)效性也

　　是同樣重要的。那mysql它什么時(shí)候自動(dòng)更新統(tǒng)計(jì)信息呢？默認(rèn)情況下當(dāng)表中的數(shù)據(jù)有10%被修改過(guò)的就會(huì)更新。

三、mysql對(duì)統(tǒng)計(jì)信息的處理：

　　針對(duì)上面的兩個(gè)問(wèn)題mysql都有給出解決方案，并且都可能通過(guò)簡(jiǎn)單的配置來(lái)解決

　　1、針對(duì)是否持久化統(tǒng)計(jì)信息mysql可以通過(guò)innodb_stats_persistent參數(shù)來(lái)控制

　　2、針對(duì)統(tǒng)計(jì)信息的時(shí)效性，mysql通過(guò)innodb_stats_auto_recalc參數(shù)來(lái)控制是否自動(dòng)更新

　　3、針對(duì)統(tǒng)計(jì)信息的準(zhǔn)確性，mysql通過(guò)innodb_stats_persistent_sample_pages 參數(shù)來(lái)控制更新

　　統(tǒng)計(jì)信息時(shí)的采樣，樣本頁(yè)面的數(shù)量。

四、手動(dòng)更新統(tǒng)計(jì)信息的方式：

　　mysql通過(guò)analyze table 語(yǔ)句來(lái)手動(dòng)的更新統(tǒng)計(jì)信息

五、查看表的統(tǒng)計(jì)信息是什么時(shí)候更新的：

　　mysql把統(tǒng)計(jì)信息相關(guān)的內(nèi)容記錄在mysql.innodb_table_stats ，mysql.innodb_index_stats 這兩張表里面。

　　mysql.innodb_table_stats以表為單位記錄著統(tǒng)計(jì)信息

mysql> select * from innodb_table_stats;
+---------------+----------------------------+---------------------+--------+----------------------+--------------------------+
| database_name | table_name         | last_update     | n_rows | clustered_index_size | sum_of_other_index_sizes |
+---------------+----------------------------+---------------------+--------+----------------------+--------------------------+
| fdb      | auth_group         | 2017-08-10 14:36:40 |   0 |          1 |            1 |
| fdb      | auth_group_permissions   | 2017-08-10 14:36:41 |   0 |          1 |            2 |
| fdb      | auth_permission      | 2017-08-10 14:36:41 |   30 |          1 |            1 |
| fdb      | auth_user         | 2017-08-10 14:36:41 |   0 |          1 |            1 |
| fdb      | auth_user_groups      | 2017-08-10 14:36:41 |   0 |          1 |            2 |
| fdb      | auth_user_user_permissions | 2017-08-10 14:36:41 |   0 |          1 |            2 |
| fdb      | cninfo_company       | 2017-08-10 14:36:58 |  4996 |         161 |            6 |
| fdb      | csindex_indexdetail    | 2017-09-17 14:04:27 |   0 |          1 |            0 |
| fdb      | csindex_indexoverview   | 2017-09-01 12:44:18 |   11 |          1 |            0 |
| fdb      | django_admin_log      | 2017-08-10 14:36:47 |   0 |          1 |            2 |
| fdb      | django_content_type    | 2017-08-10 14:36:47 |   10 |          1 |            1 |
| fdb      | django_migrations     | 2017-09-04 14:04:09 |   37 |          1 |            0 |
| fdb      | django_session       | 2017-08-10 14:36:47 |   0 |          1 |            1 |
| fdb      | glod_glodprice       | 2017-08-10 14:36:48 |  2271 |          10 |            0 |
| fdb      | pbc_moneysupply      | 2017-08-10 14:37:08 |   78 |          1 |            0 |
| fdb      | shibor_shiborrate     | 2017-08-10 14:37:18 |  2711 |          14 |            0 |
| fdb      | sse_marketoverview     | 2017-08-15 16:06:12 |   0 |          1 |            0 |
| mysql     | gtid_executed       | 2017-09-06 11:02:14 |   2 |          1 |            0 |
| sys      | sys_config         | 2017-08-10 12:19:06 |   6 |          1 |            0 |
| tempdb    | person           | 2017-09-14 11:18:15 |   1 |          1 |            0 |
| tmp      | t             | 2017-08-15 11:06:18 |   2 |          1 |            0 |
+---------------+----------------------------+---------------------+--------+----------------------+--------------------------+
21 rows in set (0.00 sec)

　　各個(gè)列所代表的意義：

　　database_name　　　　　　　　表所在的庫(kù)名

　　table_name　　　　　　　　　　表名

　　last_update　　　　　　　　　　最近一次的更新時(shí)間

　　n_rows　　　　　　　　　　　　表中的行數(shù)

　　clustered_index_size　　　　　主鍵的大小

　　sum_of_other_index_sizes　　　所有二級(jí)索引的大小

六、一些在analyze table 過(guò)程中的經(jīng)驗(yàn)：

　　如果我們用explan 語(yǔ)句查看SQL的執(zhí)行計(jì)劃的時(shí)候發(fā)現(xiàn)，計(jì)劃走的不準(zhǔn)，多半是由于統(tǒng)計(jì)信息過(guò)時(shí)引起的，這個(gè)

　　時(shí)候就要執(zhí)行一下analyze table 來(lái)重新生成一下執(zhí)行計(jì)劃了；有時(shí)候可能發(fā)現(xiàn)重新生成執(zhí)行計(jì)劃后并沒(méi)有什么用

　　SQL還是走的不準(zhǔn)，這個(gè)時(shí)候最可能的原因就是生成執(zhí)行計(jì)劃時(shí)的采樣頁(yè)的數(shù)量太低了，innodb_stats_persistent_sample_pages

　　這個(gè)參數(shù)的值，注意這個(gè)值也不要加的太大，要不然會(huì)老半天都執(zhí)行不完analyze table 語(yǔ)句?！　?/p>