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

關(guān)注我們

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

DING！

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

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

什么是SQL呢？

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

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

簡單的信息說好了，那我們開始吧。(別怕看不懂，小編陪著你一起看！)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

索引失效的場景都有哪些？

隱式轉(zhuǎn)換

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

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

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

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

innodb_stats_method?

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

innodb_stats_auto_recalc?

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

innodb_stats_on_metadata?

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

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

innodb_stats_persistent?

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

innodb_stats_persistent_sample_pages?

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

innodb_stats_transient_sample_pages?

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

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

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

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

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

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

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

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

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

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

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

就?

我知道你在看喲

總結(jié)

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

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