點(diǎn)擊藍(lán)字

關(guān)注我們

在正文開(kāi)始前，我們先補(bǔ)充一輪知識(shí)點(diǎn)。

DING！

什么叫統(tǒng)計(jì)信息？

統(tǒng)計(jì)信息是數(shù)據(jù)庫(kù)對(duì)所有表信息進(jìn)行數(shù)據(jù)抽樣后得出的數(shù)據(jù)統(tǒng)計(jì)，它是一個(gè)數(shù)據(jù)庫(kù)優(yōu)化器選擇最佳執(zhí)行計(jì)劃的核心依據(jù)。

什么是SQL呢？

SQL就是一種在數(shù)據(jù)庫(kù)中的結(jié)構(gòu)化查詢語(yǔ)言，就像英語(yǔ)在世界上的地位一樣，在不同的數(shù)據(jù)庫(kù)都可以用SQL這個(gè)語(yǔ)言。

它主要是對(duì)數(shù)據(jù)進(jìn)行定義、操縱和管理，就是可以對(duì)數(shù)據(jù)進(jìn)行整理，產(chǎn)生約束的條件，還有查詢數(shù)據(jù)、修改數(shù)據(jù)和進(jìn)行用戶權(quán)限的管理。

簡(jiǎn)單的信息說(shuō)好了，那我們開(kāi)始吧。(別怕看不懂，小編陪著你一起看！)

在一個(gè)風(fēng)和日麗的下午，奮哥哥突然接到業(yè)務(wù)方線上業(yè)務(wù)數(shù)據(jù)庫(kù)CPU資源告警信息(數(shù)據(jù)庫(kù)出現(xiàn)了問(wèn)題)，奮哥哥立馬放下手里的枸杞杯登錄業(yè)務(wù)方阿里云控制臺(tái)查看具體問(wèn)題。

對(duì)于數(shù)據(jù)庫(kù)當(dāng)前正在發(fā)生中的問(wèn)題，我們首先從數(shù)據(jù)庫(kù)實(shí)時(shí)會(huì)話信息中嘗試抓取有效信息，可以看到該告警實(shí)例的會(huì)話已經(jīng)出現(xiàn)堆積狀態(tài)，大量會(huì)話處于"Sending data"狀態(tài)(正在向客戶發(fā)送數(shù)據(jù))且從TIME字段可以看到這些會(huì)話長(zhǎng)時(shí)間執(zhí)行未結(jié)束。

會(huì)話長(zhǎng)時(shí)間執(zhí)行表示當(dāng)前會(huì)話一直占用的數(shù)據(jù)庫(kù)資源未釋放，且堆積會(huì)話基本為同一類型的業(yè)務(wù)SQL，這也就是導(dǎo)致我們數(shù)據(jù)庫(kù)CPU資源占用過(guò)高的問(wèn)題SQL。

我們拎出這個(gè)問(wèn)題SQL(問(wèn)題代碼)登錄數(shù)據(jù)庫(kù)查看SQL的執(zhí)行計(jì)劃，對(duì)問(wèn)題SQL進(jìn)行分析，從SQL執(zhí)行計(jì)劃中我們很明顯發(fā)現(xiàn)一個(gè)資源消耗比較大的操作"ALL"全表掃描操作，而且比較詭異的一點(diǎn)是，a表進(jìn)行表關(guān)聯(lián)possible_keys(可能使用到的索引)明明是primary(主鍵索引)但是卻沒(méi)有使用，所以我們下一步的方向就是排查為什么表關(guān)聯(lián)沒(méi)有有效利用索引。

導(dǎo)致索引失效的問(wèn)題的原因最常見(jiàn)的就是隱式轉(zhuǎn)換(系統(tǒng)自動(dòng)識(shí)別轉(zhuǎn)換)，關(guān)于隱式轉(zhuǎn)換我們之前的文章也做過(guò)比較詳細(xì)的講解，總體概括主要是以下幾個(gè)場(chǎng)景：

1.傳遞數(shù)據(jù)類型和字段類型不一致

2.關(guān)聯(lián)字段類型不一致

3.關(guān)聯(lián)字段字符集不一致

4.校驗(yàn)規(guī)則不一致

在表關(guān)聯(lián)字段索引失效的情況下，可能導(dǎo)致索引失效的場(chǎng)景主要是2～4，于是我們馬上查看表關(guān)聯(lián)字段相關(guān)信息進(jìn)行一一驗(yàn)證。emmmm，查詢到的結(jié)果卻似乎有些不盡人意，表關(guān)聯(lián)字段均是bigint類型(一種數(shù)據(jù)類型)，完美的規(guī)避掉了以上所有可能。

再次陷入沉思，在沒(méi)有發(fā)生隱式轉(zhuǎn)換的情況下索引一般都是會(huì)有效利用的，除非MySQL優(yōu)化器認(rèn)為ALL全表掃描的效率并不差。

我們知道，MySQL優(yōu)化器會(huì)通過(guò)具體表的統(tǒng)計(jì)信息基于CBO(基于成本的優(yōu)化)進(jìn)行代價(jià)計(jì)算，幫我們選擇最佳執(zhí)行計(jì)劃。

但是統(tǒng)計(jì)信息并不是完全精確的，某些時(shí)候可能會(huì)出現(xiàn)一定的誤差，也正是因?yàn)榻y(tǒng)計(jì)信息的誤差，就可能導(dǎo)致MySQL優(yōu)化器錯(cuò)誤的選擇一個(gè)并不是很好的"最佳執(zhí)行計(jì)劃"。

接下來(lái)我們就可以進(jìn)一步查看表的統(tǒng)計(jì)信息以及hint(強(qiáng)制SQL走指定索引)進(jìn)行驗(yàn)證。

表關(guān)聯(lián)對(duì)應(yīng)的統(tǒng)計(jì)信息

通過(guò)hint強(qiáng)制走primary索引

觀察執(zhí)行計(jì)劃并測(cè)試執(zhí)行效率

問(wèn)題排查到這里，導(dǎo)致該SQL大量消耗CPU資源的原因也就水落石出了。

對(duì)于業(yè)務(wù)方目前的CPU資源占用過(guò)高的情況，我們可以建議業(yè)務(wù)方先將目前堆積的會(huì)話進(jìn)行Kill(將會(huì)話刪除)，避免影響其他正常的業(yè)務(wù)查詢，等數(shù)據(jù)庫(kù)CPU資源有所回落后，在數(shù)據(jù)庫(kù)執(zhí)行"analyze table"對(duì)問(wèn)題表的統(tǒng)計(jì)信息重新采集，統(tǒng)計(jì)信息更新后MySQL優(yōu)化器就可以正確的選擇最佳執(zhí)行計(jì)劃。

統(tǒng)計(jì)信息更新

執(zhí)行計(jì)劃更新

雖然客戶的問(wèn)題已經(jīng)處理，對(duì)于本案例還是有一些點(diǎn)值得我們思考：

索引失效的場(chǎng)景都有哪些？

隱式轉(zhuǎn)換

統(tǒng)計(jì)信息不準(zhǔn)確

MySQL統(tǒng)計(jì)信息是如何更新采集？

在MySQL中有一些參數(shù)設(shè)置決定了統(tǒng)計(jì)信息采集的行為方式，一般情況下不會(huì)做特別設(shè)置，我們需要正確的理解這些參數(shù)，明白統(tǒng)計(jì)信息只是一個(gè)統(tǒng)計(jì)估計(jì)值，并不是絕對(duì)精準(zhǔn)。

統(tǒng)計(jì)信息相關(guān)參數(shù)

innodb_stats_method?

默認(rèn)nulls_equal，表示統(tǒng)計(jì)信息時(shí)把所有的null當(dāng)作等值對(duì)待

innodb_stats_auto_recalc?

是否打開(kāi)自動(dòng)化采集統(tǒng)計(jì)數(shù)據(jù) ，默認(rèn)打開(kāi)，當(dāng)表數(shù)據(jù)量更新10%觸發(fā)重新采集統(tǒng)計(jì)信息

innodb_stats_on_metadata?

默認(rèn)關(guān)閉，若該參數(shù)開(kāi)啟時(shí)表示數(shù)據(jù)庫(kù)執(zhí)行"show table status",

訪問(wèn)"INFORMATION_SCHEMA.TABLES or INFORMATION_SCHEMA.STATISTICS"時(shí)，都會(huì)觸發(fā)重新采集統(tǒng)計(jì)信息的操作

innodb_stats_persistent?

統(tǒng)計(jì)信息是否持久化到磁盤，默認(rèn)打開(kāi)。持久化磁盤當(dāng)數(shù)據(jù)庫(kù)重新啟動(dòng)后可從磁盤讀取。

innodb_stats_persistent_sample_pages?

默認(rèn)20，對(duì)于持久化存儲(chǔ)統(tǒng)計(jì)信息的表，每次重新采集信息需要采集20個(gè)索引頁(yè)進(jìn)行分析

innodb_stats_transient_sample_pages?

默認(rèn)8，對(duì)于非持久化的表，其統(tǒng)計(jì)信息重新采集需要掃描8個(gè)索引頁(yè)進(jìn)行分析

MySQL幾種重新采集統(tǒng)計(jì)信息的時(shí)機(jī)

1.新打開(kāi)一張表時(shí)

表數(shù)據(jù)變更超過(guò)10%觸發(fā)該表的統(tǒng)計(jì)信息重新采集當(dāng)innodb_stats_on_metadata參數(shù)打開(kāi)，數(shù)據(jù)庫(kù)執(zhí)行"show table status",訪問(wèn)"INFORMATION_SCHEMA.TABLES or INFORMATION_SCHEMA.STATISTICS"時(shí)

2.手動(dòng)執(zhí)行analyze tables時(shí)

關(guān)于analyze table操作：執(zhí)行該操作需要具有該表的select/insert權(quán)限；支持Innodb、Myisam、NDB存儲(chǔ)引擎下的表，不支持視圖；支持對(duì)分區(qū)表中某個(gè)分區(qū)單獨(dú)執(zhí)行統(tǒng)計(jì)分析；alter table ... analyze partition在執(zhí)行analyze期間，會(huì)對(duì)該表加一個(gè)。

在探索完技術(shù)的真理后，奮哥哥默默的拿起了之前放下的枸杞杯又悠哉了起來(lái)。

小編在這里做一下總結(jié)哦，來(lái)幫助大家理解。

簡(jiǎn)單來(lái)講，這是一個(gè)由于索引失效而導(dǎo)致的數(shù)據(jù)庫(kù)CPU資源占用過(guò)高的問(wèn)題，在解決這個(gè)問(wèn)題的過(guò)程中探尋出索引失效的原因：MySQL優(yōu)化器根據(jù)錯(cuò)誤的統(tǒng)計(jì)信息選擇一個(gè)并不是很好的"最佳執(zhí)行計(jì)劃"。

通常發(fā)生這種情況，我們建議先將目前堆積的會(huì)話進(jìn)行刪除，避免影響其他正常的業(yè)務(wù)查詢，等數(shù)據(jù)庫(kù)CPU資源有所回落后，在數(shù)據(jù)庫(kù)執(zhí)行"analyze table"(統(tǒng)計(jì)索引分布信息)對(duì)問(wèn)題表的統(tǒng)計(jì)信息重新采集，統(tǒng)計(jì)信息更新后MySQL優(yōu)化器就可以正確的選擇最佳執(zhí)行計(jì)劃。

如果還有不明白的地方歡迎大家點(diǎn)擊“在看”進(jìn)行留言，和小編進(jìn)行討論哦！

就?

我知道你在看喲

總結(jié)

以上是生活随笔為你收集整理的mysql 非自然月统计_技本功|统计信息对SQL执行效率的影响的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。