建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
mysql數(shù)據(jù)庫(kù)突然變慢 數(shù)據(jù)庫(kù)變慢是什么原因
MySQL 在崩潰恢復(fù)時(shí)，會(huì)遍歷打開(kāi)所有 ibd 文件的 header page 驗(yàn)證數(shù)據(jù)字典的準(zhǔn)確性，如果 MySQL 中包含了大量表，這個(gè)校驗(yàn)過(guò)程就會(huì)比較耗時(shí)。 MySQL 下崩潰恢復(fù)確實(shí)和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時(shí)間越長(zhǎng)。另外磁盤(pán) IOPS 也會(huì)影響崩潰恢復(fù)時(shí)間，像這里開(kāi)發(fā)庫(kù)的 HDD IOPS 較低，因此面對(duì)大量的表空間，校驗(yàn)速度就非常緩慢。另外一個(gè)發(fā)現(xiàn)，MySQL 8 下正常啟用時(shí)居然也會(huì)進(jìn)行表空間校驗(yàn)，而故障恢復(fù)時(shí)則會(huì)額外再進(jìn)行一次表空間校驗(yàn)，等于校驗(yàn)了 2 遍。不過(guò) MySQL 8.0 里多了一個(gè)特性，即表數(shù)量超過(guò) 5W 時(shí)，會(huì)啟用多線程掃描，加快表空間校驗(yàn)過(guò)程。
創(chuàng)新互聯(lián)建站作為成都網(wǎng)站建設(shè)公司，專(zhuān)注成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)，有關(guān)成都企業(yè)網(wǎng)站建設(shè)方案、改版、費(fèi)用等問(wèn)題，行業(yè)涉及成都假山制作等多個(gè)領(lǐng)域，已為上千家企業(yè)服務(wù)，得到了客戶(hù)的尊重與認(rèn)可。
如何跳過(guò)校驗(yàn)MySQL 5.7 下有方法可以跳過(guò)崩潰恢復(fù)時(shí)的表空間校驗(yàn)過(guò)程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過(guò)表空間校驗(yàn)。實(shí)際測(cè)試的時(shí)候設(shè)置 innodb_force_recovery =1，也就是強(qiáng)制恢復(fù)跳過(guò)壞頁(yè)，就可以跳過(guò)校驗(yàn)，然后重啟就是正常啟動(dòng)了。通過(guò)這種臨時(shí)方式可以避免崩潰恢復(fù)后非常耗時(shí)的表空間校驗(yàn)過(guò)程，快速啟動(dòng) MySQL，個(gè)人目前暫時(shí)未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨(dú)立表空間這樣就不需要打開(kāi) N 個(gè) ibd 文件了，只需要打開(kāi)一個(gè) ibdata 文件即可，大大節(jié)省了校驗(yàn)時(shí)間。自從聽(tīng)了姜老師講過(guò)使用共享表空間替代獨(dú)立表空間解決 drop 大表時(shí)性能抖動(dòng)的原理后，感覺(jué)共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢(shì)。
臨時(shí)冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過(guò)臨時(shí)修改 validate 變量值讓 MySQL 跳過(guò)表空間驗(yàn)證過(guò)程，然后讓 MySQL 正常關(guān)閉，重新啟動(dòng)就可以正常啟動(dòng)了。但是實(shí)際測(cè)試發(fā)現(xiàn)，如果以 debug 模式運(yùn)行，確實(shí)可以臨時(shí)修改 validate 變量，跳過(guò)表空間驗(yàn)證過(guò)程，但是 debug 模式下代碼運(yùn)行效率大打折扣，反而耗時(shí)更長(zhǎng)。而以非 debug 模式運(yùn)行，則無(wú)法修改 validate 變量，想法破滅。
MySQL速度變慢，怎么辦
MySQL 在崩潰恢復(fù)時(shí)，會(huì)遍歷打開(kāi)所有 ibd 文件的 header page 驗(yàn)證數(shù)據(jù)字典的準(zhǔn)確性，如果 MySQL 中包含了大量表，這個(gè)校驗(yàn)過(guò)程就會(huì)比較耗時(shí)。 MySQL 下崩潰恢復(fù)確實(shí)和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時(shí)間越長(zhǎng)。另外磁盤(pán) IOPS 也會(huì)影響崩潰恢復(fù)時(shí)間，像這里開(kāi)發(fā)庫(kù)的 HDD IOPS 較低，因此面對(duì)大量的表空間，校驗(yàn)速度就非常緩慢。另外一個(gè)發(fā)現(xiàn)，MySQL 8 下正常啟用時(shí)居然也會(huì)進(jìn)行表空間校驗(yàn)，而故障恢復(fù)時(shí)則會(huì)額外再進(jìn)行一次表空間校驗(yàn)，等于校驗(yàn)了 2 遍。不過(guò) MySQL 8.0 里多了一個(gè)特性，即表數(shù)量超過(guò) 5W 時(shí)，會(huì)啟用多線程掃描，加快表空間校驗(yàn)過(guò)程。
如何跳過(guò)校驗(yàn)MySQL 5.7 下有方法可以跳過(guò)崩潰恢復(fù)時(shí)的表空間校驗(yàn)過(guò)程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過(guò)表空間校驗(yàn)。實(shí)際測(cè)試的時(shí)候設(shè)置 innodb_force_recovery =1，也就是強(qiáng)制恢復(fù)跳過(guò)壞頁(yè)，就可以跳過(guò)校驗(yàn)，然后重啟就是正常啟動(dòng)了。通過(guò)這種臨時(shí)方式可以避免崩潰恢復(fù)后非常耗時(shí)的表空間校驗(yàn)過(guò)程，快速啟動(dòng) MySQL，個(gè)人目前暫時(shí)未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨(dú)立表空間這樣就不需要打開(kāi) N 個(gè) ibd 文件了，只需要打開(kāi)一個(gè) ibdata 文件即可，大大節(jié)省了校驗(yàn)時(shí)間。自從聽(tīng)了姜老師講過(guò)使用共享表空間替代獨(dú)立表空間解決 drop 大表時(shí)性能抖動(dòng)的原理后，感覺(jué)共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢(shì)。
臨時(shí)冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過(guò)臨時(shí)修改 validate 變量值讓 MySQL 跳過(guò)表空間驗(yàn)證過(guò)程，然后讓 MySQL 正常關(guān)閉，重新啟動(dòng)就可以正常啟動(dòng)了。但是實(shí)際測(cè)試發(fā)現(xiàn)，如果以 debug 模式運(yùn)行，確實(shí)可以臨時(shí)修改 validate 變量，跳過(guò)表空間驗(yàn)證過(guò)程，但是 debug 模式下代碼運(yùn)行效率大打折扣，反而耗時(shí)更長(zhǎng)。而以非 debug 模式運(yùn)行，則無(wú)法修改 validate 變量，想法破滅。
Mysql 查詢(xún)速度慢怎么辦
問(wèn)題
我們有一個(gè) SQL，用于找到?jīng)]有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運(yùn)行特別慢，怎么辦？
實(shí)驗(yàn)
我們搭建一個(gè) MySQL 5.7 的環(huán)境，此處省略搭建步驟。
寫(xiě)個(gè)簡(jiǎn)單的腳本，制造一批帶主鍵和不帶主鍵的表：
執(zhí)行一下腳本：
現(xiàn)在執(zhí)行以下 SQL 看看效果：
...
執(zhí)行了 16.80s，感覺(jué)是非常慢了。
現(xiàn)在用一下 DBA 三板斧，看看執(zhí)行計(jì)劃：
感覺(jué)有點(diǎn)慘，由于 information_schema.columns 是元數(shù)據(jù)表，沒(méi)有必要的統(tǒng)計(jì)信息。
那我們來(lái) show warnings 看看 MySQL 改寫(xiě)后的 SQL：
我們格式化一下 SQL：
可以看到 MySQL 將
select from A where A.x not in (select x from B) //非關(guān)聯(lián)子查詢(xún)
轉(zhuǎn)換成了
select from A where not exists (select 1 from B where B.x = a.x) //關(guān)聯(lián)子查詢(xún)
如果我們自己是 MySQL，在執(zhí)行非關(guān)聯(lián)子查詢(xún)時(shí)，可以使用很簡(jiǎn)單的策略：
select from A where A.x not in (select x from B where ...) //非關(guān)聯(lián)子查詢(xún):1. 掃描 B 表中的所有記錄，找到滿(mǎn)足條件的記錄，存放在臨時(shí)表 C 中，建好索引2. 掃描 A 表中的記錄，與臨時(shí)表 C 中的記錄進(jìn)行比對(duì)，直接在索引里比對(duì)，
而關(guān)聯(lián)子查詢(xún)就需要循環(huán)迭代：
select from A where not exists (select 1 from B where B.x = a.x and ...) //關(guān)聯(lián)子查詢(xún)掃描 A 表的每一條記錄 rA： ? ? 掃描 B 表，找到其中的第一條滿(mǎn)足 rA 條件的記錄。
顯然，關(guān)聯(lián)子查詢(xún)的掃描成本會(huì)高于非關(guān)聯(lián)子查詢(xún)。
我們希望 MySQL 能先"緩存"子查詢(xún)的結(jié)果（緩存這一步叫物化，MATERIALIZATION），但MySQL 認(rèn)為不緩存更快，我們就需要給予 MySQL 一定指導(dǎo)。
...
可以看到執(zhí)行時(shí)間變成了 0.67s。
整理
我們?cè)\斷的關(guān)鍵點(diǎn)如下：
\1. 對(duì)于 information_schema 中的元數(shù)據(jù)表，執(zhí)行計(jì)劃不能提供有效信息。
\2. 通過(guò)查看 MySQL 改寫(xiě)后的 SQL，我們猜測(cè)了優(yōu)化器發(fā)生了誤判。
\3. 我們?cè)黾恿?hint，指導(dǎo) MySQL 正確進(jìn)行優(yōu)化判斷。
但目前我們的實(shí)驗(yàn)僅限于猜測(cè)，猜中了萬(wàn)事大吉，猜不中就無(wú)法做出好的診斷。
mysql 存儲(chǔ)過(guò)程執(zhí)行太慢怎么優(yōu)化
1.當(dāng)我們請(qǐng)求mysql服務(wù)器的時(shí)候,MySQL前端會(huì)有一個(gè)監(jiān)聽(tīng),請(qǐng)求到了之后,服務(wù)器得到相關(guān)的SQL語(yǔ)句,執(zhí)行之前(虛線部分為執(zhí)行),還會(huì)做權(quán)限的判斷
2.通過(guò)權(quán)限之后,SQL就到MySQL內(nèi)部,他會(huì)在查詢(xún)緩存中,看該SQL有沒(méi)有執(zhí)行過(guò),如果有查詢(xún)過(guò),則把緩存結(jié)果返回,說(shuō)明在MySQL內(nèi)部,也有一個(gè)查詢(xún)緩存.但是這個(gè)查詢(xún)緩存,默認(rèn)是不開(kāi)啟的,這個(gè)查詢(xún)緩存,和我們的Hibernate，Mybatis的查詢(xún)緩存是一樣的,因?yàn)椴樵?xún)緩存要求SQL和參數(shù)都要一樣,所以這個(gè)命中率是非常低的（沒(méi)什么卵用的意思）。
3.如果我們沒(méi)有開(kāi)啟查詢(xún)緩存,或者緩存中沒(méi)有找到對(duì)應(yīng)的結(jié)果,那么就到了解析器,解析器主要對(duì)SQL語(yǔ)法進(jìn)行解析
4.解析結(jié)束后就變成一顆解析樹(shù),這個(gè)解析樹(shù)其實(shí)在Hibernate里面也是有的,大家回憶一下,在以前做過(guò)Hibernate項(xiàng)目的時(shí)候,是不是有個(gè)一個(gè)antlr.jar。這個(gè)就是專(zhuān)門(mén)做語(yǔ)法解析的工具.因?yàn)樵贖ibernate里面有HQL，它就是通過(guò)這個(gè)工具轉(zhuǎn)換成SQL的,我們編程語(yǔ)言之所以有很多規(guī)范、語(yǔ)法,其實(shí)就是為了便于這個(gè)解析器解析,這個(gè)學(xué)過(guò)編譯原理的應(yīng)該知道.
5.得到解析樹(shù)之后,不能馬上執(zhí)行,這還需要對(duì)這棵樹(shù)進(jìn)行預(yù)處理,也就是說(shuō),這棵樹(shù),我沒(méi)有經(jīng)過(guò)任何優(yōu)化的樹(shù),預(yù)處理器會(huì)這這棵樹(shù)進(jìn)行一些預(yù)處理,比如常量放在什么地方,如果有計(jì)算的東西,把計(jì)算的結(jié)果算出來(lái)等等...
6.預(yù)處理完畢之后,此時(shí)得到一棵比較規(guī)范的樹(shù),這棵樹(shù)就是要拿去馬上做執(zhí)行的樹(shù),比起之前的那棵樹(shù),這棵得到了一些優(yōu)化
7.查詢(xún)優(yōu)化器，是MySQL里面最關(guān)鍵的東西,我們寫(xiě)任何一條SQL,比如SELECT * FROM USER WHERE USERNAME = toby AND PASSWORD = 1,它會(huì)怎么去執(zhí)行?它是先執(zhí)行username = toby還是password = 1?每一條SQL的執(zhí)行順序查詢(xún)優(yōu)化器就是根據(jù)MySQL對(duì)數(shù)據(jù)統(tǒng)計(jì)表的一些信息,比如索引,比如表一共有多少數(shù)據(jù),MySQL都是有緩存起來(lái)的,在真正執(zhí)行SQL之前,他會(huì)根據(jù)自己的這些數(shù)據(jù),進(jìn)行一個(gè)綜合的判定,判斷這一次在多種執(zhí)行方式里面,到底選哪一種執(zhí)行方式,可能運(yùn)行的最快.這一步是MySQL性能中,最關(guān)鍵的核心點(diǎn),也是我們的優(yōu)化原則.我們平時(shí)所講的優(yōu)化SQL,其實(shí)說(shuō)白了,就是想讓查詢(xún)優(yōu)化器,按照我們的想法,幫我們選擇最優(yōu)的執(zhí)行方案,因?yàn)槲覀儽萂ySQL更懂我們的數(shù)據(jù).MySQL看數(shù)據(jù),僅僅只是自己收集到的信息,這些信息可能是不準(zhǔn)確的,MySQL根據(jù)這些信息選了一個(gè)它自認(rèn)為最優(yōu)的方案,但是這個(gè)方案可能和我們想象的不一樣.
8.這里的查詢(xún)執(zhí)行計(jì)劃,也就是MySQL查詢(xún)中的執(zhí)行計(jì)劃,比如要先執(zhí)行username = toby還是password = 1
9.這個(gè)執(zhí)行計(jì)劃會(huì)傳給查詢(xún)執(zhí)行引擎,執(zhí)行引擎選擇存儲(chǔ)引擎來(lái)執(zhí)行這一份傳過(guò)來(lái)的計(jì)劃,到磁盤(pán)中的文件中去查詢(xún),這個(gè)時(shí)候重點(diǎn)來(lái)了,影響這個(gè)查詢(xún)性能最根本的原因是什么?就是硬盤(pán)的機(jī)械運(yùn)動(dòng),也就是我們平時(shí)熟悉的IO,所以一條查詢(xún)語(yǔ)句是快還是慢,就是根據(jù)這個(gè)時(shí)間的IO來(lái)確定的.那怎么執(zhí)行IO又是什么來(lái)確定的?就是傳過(guò)來(lái)的這一份執(zhí)行計(jì)劃.(優(yōu)化就是制定一個(gè)我們認(rèn)為最快的執(zhí)行方案,最節(jié)省IO,和執(zhí)行最快)
10.如果開(kāi)了查詢(xún)緩存,則返回結(jié)果給客戶(hù)端,并且查詢(xún)緩存也放一份。
網(wǎng)頁(yè)題目：mysql卡慢怎么辦 mysql數(shù)據(jù)庫(kù)卡頓
URL標(biāo)題：http://www.ef60e0e.cn/article/doepgec.html
