MySQL中怎么實(shí)現(xiàn)統(tǒng)計(jì)信息持久化，針對這個(gè)問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

創(chuàng)新互聯(lián)專注于閩侯企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè),商城網(wǎng)站建設(shè)。閩侯網(wǎng)站建設(shè)公司,為閩侯等地區(qū)提供建站服務(wù)。全流程按需定制網(wǎng)站，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

在任何數(shù)據(jù)庫中統(tǒng)計(jì)信息是幫助數(shù)據(jù)庫查詢中走更適合的查詢路徑的基礎(chǔ)，MYSQL 8 中持久化的統(tǒng)計(jì)信息怎么做，怎么能持久化后提高執(zhí)行計(jì)劃的穩(wěn)定性。

默認(rèn)的情況下，這個(gè)參數(shù)是打開的

show variables like 'innodb_stats_persistent';

實(shí)際當(dāng)中統(tǒng)計(jì)信息是存在于mysql.innodb_table_stats   and  mysql.innodb_index_stats 這兩個(gè)表中的

具體每個(gè)表變化多少數(shù)據(jù)量才開始進(jìn)行統(tǒng)計(jì)，要看 innodb_stats_auto_recalc 這個(gè)參數(shù)，默認(rèn)打開，并且一個(gè)表中的10%的行進(jìn)行變化了，才開始統(tǒng)計(jì)信息的重新計(jì)算。

實(shí)際上下面的某些東西可能和有些開源數(shù)據(jù)庫有類似的地方了，可以調(diào)整的參數(shù)是在表的層面還是數(shù)據(jù)庫層面，都可以細(xì)微的調(diào)整了，因?yàn)槲覀儾荒茏屆總€(gè)表的數(shù)據(jù)的增量都一致，假象一個(gè)表一天的增量是100萬行，一個(gè)是50行，那統(tǒng)計(jì)分析如果已按照所有的表一樣的方式來進(jìn)行統(tǒng)計(jì)，這顯然是有點(diǎn)欠妥。

所以上面的截圖就是一個(gè)類似細(xì)微調(diào)整的參數(shù)

stats_persistent = 1 是要持久化性能計(jì)數(shù)器

stats_auto_recale 是控制這個(gè)表到底要不要進(jìn)行自動的性能分析，例如有人ORACLE 用的順手了，很可能會在晚上的時(shí)間來跑一邊統(tǒng)計(jì)分析，這里 stats_auto_recalc 這里的意思是是否你要自動的進(jìn)行還是手動， 最后的stats_sample_pages 是針對你索引的統(tǒng)計(jì)信息的精度，默認(rèn)是20，增加這個(gè)數(shù)值可以提高統(tǒng)計(jì)信息的精度，當(dāng)然你也要付出某些磁盤空間，和分析時(shí)的cpu等資源。

所以這樣就對一個(gè)大表是經(jīng)常被查詢的HOT TABLE 還是 COLD TABLE 在這里進(jìn)行分析，雖然這個(gè)表大量插入數(shù)據(jù)，但實(shí)際上查詢很少，則可以降低 stats_sample_pages 的隨機(jī)抽樣的數(shù)字。相反，則可以適當(dāng)增加。

我們來做一個(gè)測試，關(guān)于往數(shù)據(jù)庫中插入數(shù)據(jù)，但之前需要注意的是PYTHON 與MYSQL 8.019相連接需要新的連接方式 mysql_connector_python  而不是之前的方式，上圖的還在繼續(xù)用老的方式需要將你的賬戶的。

CREATE USER link@'%' IDENTIFIED WITH mysql_native_password BY 'link';  否則連接中會報(bào)錯

另外還有一點(diǎn)是，在統(tǒng)計(jì)分析中默認(rèn)是針對 READ UNCOMMITED  的方式，其中如果有刪除的記錄，同時(shí)被標(biāo)記的刪除記錄，還是要記錄到統(tǒng)計(jì)分析中，所以大量有delete操作的情況下 RC RR 方式獲得的統(tǒng)計(jì)分析信息就會相對準(zhǔn)確率低。

所以就可以將 innodb_stats_include_delete 打開。但同樣也會將統(tǒng)計(jì)分析的時(shí)間加大，并且在統(tǒng)計(jì)分析時(shí)會加重系統(tǒng)的負(fù)擔(dān)。

idx_name  n_diff_pfx01 |    1743985 |         100 | name                              idx_name   n_diff_pfx02 |    1761487 |         100 | name,id                        

idx_name   n_leaf_pages |       2722 |        NULL | Number of leaf pages 

idx_name   |  size   |     3175 |      NULL | Number of pages in the index    

從上面的拿出的文字來看，size 是顯示整體的page  數(shù)量，n_leaf_pages 是展示當(dāng)前的頁節(jié)點(diǎn)的page的數(shù)量， n_diff_pfx01 是指單列值的不同的情況，n_diff_pfx02 是顯示 兩列之間不同的值。

按照我們的MYSQL 的主鍵設(shè)置的方式，主鍵和索引列的值一般是不一樣的，所以這里可以認(rèn)為 n_diff_pfx02 大致就是你目前的表的行數(shù)（非準(zhǔn)確，因?yàn)槌霭l(fā)重新統(tǒng)計(jì)需要數(shù)據(jù)變化10%rows）

最后需要看一下NULL 值在統(tǒng)計(jì)分析中的方式 innodb_stats_method

mysql 提供了3種方式

nulls_equal   所有NULL索引值都被認(rèn)為是相等的

nulls_unequal  值被認(rèn)為是不等的，每個(gè)NULL形成大小為1的不同的值組。

nulls_ignored  忽略空值

另外這里不便展開，null = null  , no  , null != null , no  , null 在數(shù)據(jù)庫里面到底是一個(gè)什么角色，并且要不要被統(tǒng)計(jì)到統(tǒng)計(jì)信息里面來，都是應(yīng)該考慮的問題，而MYSQL 將這個(gè)問題讓用戶來選擇，實(shí)際上著也說明MYSQL 本身也對這個(gè)問題沒有自己的解決方案，所以...... 

大家在設(shè)計(jì)表的時(shí)候，盡量還是不要NULL 列，即使有，也不要INDEX it.

最后留下一幅圖，在正常的語句中，如果有null，都要在查詢中添加一個(gè) and  某字段 is null  or  某字段 not is null  ，是有意義的，否則........

關(guān)于MYSQL中怎么實(shí)現(xiàn)統(tǒng)計(jì)信息持久化問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。