資訊專(zhuān)欄INFORMATION COLUMN
背 景
MySQL引入了Materialization（物化）這一關(guān)鍵特性用于子查詢(xún)（比如在IN/NOTIN子查詢(xún)以及 FROM子查詢(xún)）優(yōu)化，其關(guān)鍵點(diǎn)在于對(duì)子查詢(xún)只需要執(zhí)行一次。具體實(shí)現(xiàn)方式為：
在SQL執(zhí)行過(guò)程中，第一次需要子查詢(xún)結(jié)果時(shí)執(zhí)行子查詢(xún)并將子查詢(xún)的結(jié)果保存為臨時(shí)表。
后續(xù)對(duì)子查詢(xún)結(jié)果集的訪問(wèn)將直接通過(guò)臨時(shí)表獲得。
與之相對(duì)的執(zhí)行方式是對(duì)外表的每一行都對(duì)子查詢(xún)進(jìn)行調(diào)用，其執(zhí)行計(jì)劃中的查詢(xún)類(lèi)型為“DEPENDENTSUBQUERY”。雖然物化子查詢(xún)有利于提高SQL的執(zhí)行效率，但如果使用不當(dāng)，會(huì)引起意想不到的后果，比如數(shù)據(jù)庫(kù)宕機(jī)，今天所講的案例就是這樣一個(gè)場(chǎng)景。
案例分析
一MySQL-5.7.17測(cè)試環(huán)境，業(yè)務(wù)發(fā)出一條查詢(xún)sql語(yǔ)句后，直接引起數(shù)據(jù)庫(kù)的宕機(jī)，查看err日志，發(fā)現(xiàn)sql語(yǔ)句如下：
| |
問(wèn)題sql為包括兩個(gè)子查詢(xún)的多表關(guān)聯(lián)select語(yǔ)句。
分析執(zhí)行計(jì)劃
| |
執(zhí)行計(jì)劃相對(duì)簡(jiǎn)單，值得注意的是select_type為“SUBQUERY”，它表明該sql可能使用了物化子查詢(xún)功能，為了得到確切的信息，查看warning信息：
| |
當(dāng)包含“materialize”和”materialized-subquery“時(shí)，已表明該sql語(yǔ)句使用了物化子查詢(xún)。為了看清物化子查詢(xún)是如何使用的，格式化上述信息如下：
| |
該sql語(yǔ)句被MySQL進(jìn)行了重寫(xiě)，并且兩個(gè)子查詢(xún)都使用了物化子查詢(xún)進(jìn)行了優(yōu)化，分配兩個(gè)臨時(shí)表用于存放子查詢(xún)的結(jié)果，并且為每個(gè)臨時(shí)表創(chuàng)建hashindex，用于關(guān)聯(lián)其它表時(shí)，提高效率。
查看optimizer_switch參數(shù)
| |
“materialization=on”表明啟用物化子查詢(xún)功能，”derived_merge=on”表明改寫(xiě)sql，將子查詢(xún)合并至外部語(yǔ)句。難道是物化子查詢(xún)這個(gè)功能引起的嗎？
關(guān)閉物化子查詢(xún)功能
| |
重新發(fā)起上述sql語(yǔ)句
| |
執(zhí)行計(jì)劃表明，該sql語(yǔ)句沒(méi)再使用物化子查詢(xún)功能
| |
該sql語(yǔ)句執(zhí)行成功，而且數(shù)據(jù)庫(kù)也并沒(méi)有宕機(jī)，看起來(lái)真的是物化子查詢(xún)這個(gè)功能的原因。
查看文檔
在查看5.7.23的變更文檔中發(fā)現(xiàn)如下這個(gè)bug
| |
上述bug說(shuō)明，物化子查詢(xún)可能會(huì)導(dǎo)致mysql服務(wù)宕機(jī)，5.7.23及以上版本修復(fù)了該問(wèn)題，運(yùn)行這樣的sql語(yǔ)句將會(huì)報(bào)錯(cuò)，而不會(huì)再導(dǎo)致mysql宕機(jī)。
測(cè)試
為了驗(yàn)證這個(gè)bug，將上述sql語(yǔ)句運(yùn)行于5.7.23版本中
| |
5.7.23版本中確實(shí)產(chǎn)生了錯(cuò)誤，并且要求關(guān)閉物化子查詢(xún)功能。
總結(jié)
啟用物化子查詢(xún)功能，可以提升包含子查詢(xún)sql的執(zhí)行效率，但也會(huì)觸發(fā)一些潛在問(wèn)題，如上述的導(dǎo)致MySQL宕機(jī)bug，雖通過(guò)升級(jí)MySQL至5.7.23或最新版本，可以避免該問(wèn)題；或閉關(guān)物化子查詢(xún)功能，使sql回退至原始的”DEPENDENT SUBQUERY“執(zhí)行方式，但相應(yīng)的sql執(zhí)行效率也會(huì)下降很多，特別是外層結(jié)果特別巨大時(shí)。所以在生產(chǎn)環(huán)境，避免子查詢(xún)的使用，才是解決該問(wèn)題的王道。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.hztianpu.com/yun/130175.html
摘要：最近的互聯(lián)網(wǎng)線上事故發(fā)生比較頻繁，年月號(hào)順豐發(fā)生了一起線上刪庫(kù)事件，在這里就不介紹了。最后的最后，線上操作的任何一條命令，再小心也不為過(guò)，因?yàn)橛捎谀愕囊粋€(gè)符號(hào)而引起的事故可能是你所承擔(dān)不起的。 摘要： 使用 Redis 的開(kāi)發(fā)者必看，吸取教訓(xùn)?。? 原文：Redis 的 KEYS 命令引起 RDS 數(shù)據(jù)庫(kù)雪崩，RDS 發(fā)生兩次宕機(jī)，造成幾百萬(wàn)的資金損失 作者：陳浩翔 Fundebu...
摘要：最近的互聯(lián)網(wǎng)線上事故發(fā)生比較頻繁，年月號(hào)順豐發(fā)生了一起線上刪庫(kù)事件，在這里就不介紹了。最后的最后，線上操作的任何一條命令，再小心也不為過(guò)，因?yàn)橛捎谀愕囊粋€(gè)符號(hào)而引起的事故可能是你所承擔(dān)不起的。 摘要： 使用 Redis 的開(kāi)發(fā)者必看，吸取教訓(xùn)??！ 原文：Redis 的 KEYS 命令引起 RDS 數(shù)據(jù)庫(kù)雪崩，RDS 發(fā)生兩次宕機(jī)，造成幾百萬(wàn)的資金損失 作者：陳浩翔 Fundebu...
摘要：與大數(shù)據(jù)體系交互上報(bào)運(yùn)行統(tǒng)計(jì)數(shù)據(jù)自帶了運(yùn)行結(jié)果的統(tǒng)計(jì)數(shù)據(jù)，我們希望把這些統(tǒng)計(jì)數(shù)據(jù)上報(bào)到元數(shù)據(jù)系統(tǒng)，作為的過(guò)程元數(shù)據(jù)存儲(chǔ)下來(lái)?；谖覀兊拈_(kāi)發(fā)策略，不要把有贊元數(shù)據(jù)系統(tǒng)的嵌入源碼，而是在之外獲取，截取出打印的統(tǒng)計(jì)信息再上報(bào)。一、需求 有贊大數(shù)據(jù)技術(shù)應(yīng)用的早期，我們使用 Sqoop 作為數(shù)據(jù)同步工具，滿(mǎn)足了 MySQL 與 Hive 之間數(shù)據(jù)同步的日常開(kāi)發(fā)需求。 隨著公司業(yè)務(wù)發(fā)展，數(shù)據(jù)同步的場(chǎng)景越...
閱讀 1459·2023-01-11 13:20
閱讀 1814·2023-01-11 13:20
閱讀 1263·2023-01-11 13:20
閱讀 2006·2023-01-11 13:20
閱讀 4226·2023-01-11 13:20
閱讀 2879·2023-01-11 13:20
閱讀 1488·2023-01-11 13:20
閱讀 3807·2023-01-11 13:20
