MySQL 在崩潰恢復時,會遍歷打開所有 ibd 文件的 header page 驗證數(shù)據(jù)字典的準確性,如果 MySQL 中包含了大量表,這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數(shù)量有關(guān),表總數(shù)越大,崩潰恢復時間越長。另外磁盤 IOPS 也會影響崩潰恢復時間,像這里開發(fā)庫的 HDD IOPS 較低,因此面對大量的表空間,校驗速度就非常緩慢。另外一個發(fā)現(xiàn),MySQL 8 下正常啟用時居然也會進行表空間校驗,而故障恢復時則會額外再進行一次表空間校驗,等于校驗了 2 遍。不過 MySQL 8.0 里多了一個特性,即表數(shù)量超過 5W 時,會啟用多線程掃描,加快表空間校驗過程。
成都創(chuàng)新互聯(lián)服務(wù)項目包括萬源網(wǎng)站建設(shè)、萬源網(wǎng)站制作、萬源網(wǎng)頁制作以及萬源網(wǎng)絡(luò)營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,萬源網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到萬源省份的部分城市,未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛?查閱了資料,方法主要有兩種:
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ,那么 validate = false,即可以跳過表空間校驗。實際測試的時候設(shè)置 innodb_force_recovery =1,也就是強制恢復跳過壞頁,就可以跳過校驗,然后重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復后非常耗時的表空間校驗過程,快速啟動 MySQL,個人目前暫時未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了,只需要打開一個 ibdata 文件即可,大大節(jié)省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理后,感覺共享表空間在很多業(yè)務(wù)環(huán)境下,反而更有優(yōu)勢。
臨時冒出另外一種解決想法,即用 GDB 調(diào)試崩潰恢復,通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程,然后讓 MySQL 正常關(guān)閉,重新啟動就可以正常啟動了。但是實際測試發(fā)現(xiàn),如果以 debug 模式運行,確實可以臨時修改 validate 變量,跳過表空間驗證過程,但是 debug 模式下代碼運行效率大打折扣,反而耗時更長。而以非 debug 模式運行,則無法修改 validate 變量,想法破滅。
兩方面
硬件:用固態(tài)硬盤、加大內(nèi)存
配置:根據(jù)內(nèi)存 調(diào)整 my.ini 里 innodb_buffer_pool_size
我們先來看第一個階段,MySQL慢的診斷思路,一般我們會從三個方向來做:
第一個方向是MySQL內(nèi)部的觀測
第二個方向是外部資源的觀測
第三個方向是外部需求的改造
1.1 MySQL 內(nèi)部觀測
我們來看MySQL內(nèi)部的觀測,常用的觀測手段是這樣的,從上往下看,第一部分是Processlist,看一下哪個SQL壓力不太正常,第二步是explain,解釋一下它的執(zhí)行計劃,第三步我們要做Profilling,如果這個SQL能再執(zhí)行一次的話, 就做一個Profilling,然后高級的DBA會直接動用performance_schema ,MySQL 5.7 以后直接動用sys_schema,sys_schema是一個視圖,里面有便捷的各類信息,幫助大家來診斷性能。再高級一點,我們會動用innodb_metrics進行一個對引擎的診斷。
除了這些手段以外,大家還提出了一些亂七八糟的手段,我就不列在這了,這些是常規(guī)的一個MySQL的內(nèi)部的狀態(tài)觀測的思路。除了這些以外,MySQL還陸陸續(xù)續(xù)提供了一些暴露自己狀態(tài)的方案,但是這些方案并沒有在實踐中形成套路,原因是學習成本比較高。
1.2 外部資源觀測
外部資源觀測這部分,我引用了一篇文章,這篇文章的二維碼我貼在上面了。這篇文章是國外的一個神寫的,標題是:60秒的快速巡檢,我們來看一下它在60秒之內(nèi)對服務(wù)器到底做了一個什么樣的巡檢。一共十條命令,這是前五條,我們一條一條來看。
1.uptime,uptime告訴我們這個機器活了多久,以及它的平均的負載是多少。
2.dmesg -T | tail,告訴我們系統(tǒng)日志里邊有沒有什么報錯。
3.vmstat 1,告訴我們虛擬內(nèi)存的狀態(tài),頁的換進換出有沒有問題,swap有沒有使用。
4. mpstat -P ALL,告訴我們CPU壓力在各個核上是不是均勻的。
5.pidstat 1,告訴我們各個進程的對資源的占用大概是什么樣子。
我們來看一下后五條:
首先是iostat-xz 1,查看IO的問題,然后是free-m內(nèi)存使用率,之后兩個sar,按設(shè)備網(wǎng)卡設(shè)備的維度,看一下網(wǎng)絡(luò)的消耗狀態(tài),以及總體看TCP的使用率和錯誤率是多少。最后一條命令top,看一下大概的進程和線程的問題。
這個就是對于外部資源的診斷,這十條命令揭示了應(yīng)該去診斷哪些外部資源。
1.3 外部需求改造
第三個診斷思路是外部的需求改造,我在這里引用了一篇文檔,這篇文檔是MySQL的官方文檔中的一章,這一章叫Examples of Common Queries,文檔中介紹了常規(guī)的SQL怎么寫, 給出了一些例子。文章的鏈接二維碼在slide上。
我們來看一下它其中提到的一個例子。
它做的事情是從一個表里邊去選取,這張表有三列,article、dealer、price,選取每個作者的最貴的商品列在結(jié)果集中,這是它的最原始的SQL,非常符合業(yè)務(wù)的寫法,但是它是個關(guān)聯(lián)子查詢。
關(guān)聯(lián)子查詢成本是很貴的,所以上面的文檔會教你快速地把它轉(zhuǎn)成一個非關(guān)聯(lián)子查詢,大家可以看到中間的子查詢和外邊的查詢之間是沒有關(guān)聯(lián)性的。
第三步,會教大家直接把子查詢拿掉,然后轉(zhuǎn)成這樣一個SQL,這個就叫業(yè)務(wù)改造,前后三個SQL的成本都不一樣,把關(guān)聯(lián)子查詢拆掉的成本,拆掉以后SQL會跑得非常好,但這個SQL已經(jīng)不能良好表義了,只有在診斷到SQL成本比較高的情況下才建議大家使用這種方式。
為什么它能夠把一個關(guān)聯(lián)子查詢拆掉呢?
這背后的原理是關(guān)系代數(shù),所有的SQL都可以被表達成等價的關(guān)系代數(shù)式,關(guān)系代數(shù)式之間有等價關(guān)系,這個等價關(guān)系通過變換可以把關(guān)聯(lián)子查詢拆掉。
上面的這篇文檔是一個大學的教材,它從頭教了關(guān)于代數(shù)和SQL之間的關(guān)系。然后一步步推導怎么去簡化這句SQL。
第一,MySQL本身提供了很多命令來觀察MySQL自身的各類狀態(tài),大家從上往下檢一般能檢到SQL的問題或者服務(wù)器的問題。
第二,從服務(wù)器的角度,我們從巡檢的腳本角度入手,服務(wù)器的資源就這幾種,觀測手法也就那么幾種,我們把服務(wù)器的資源全部都觀察一圈就可以了。
第三,如果實在搞不定,需求方一定要按照數(shù)據(jù)庫容易接受的方式去寫SQL,這個成本會下降的非常快,這個是常規(guī)的MySQL慢的診斷思路。
mysql5的手冊中提到,插入一條記錄,所需的時間比例大概是:
連接:(3)
發(fā)送查詢給服務(wù)器:(2)
分析查詢:(2)
插入記錄:(1x記錄大小)
插入索引:(1x索引)
關(guān)閉:(1)
并且表的大小以logN(B樹)的速度減慢索引的插入,因此提高插入速度的方法大概有以下7種:
一個insert語句包含多個value值;
使用insert delayed方法;
使用insert into ...values(select ...from),即select的同時執(zhí)行insert;
使用load data infile;
先禁掉索引,插入后再創(chuàng)建索引;
寫鎖表,插入,解鎖。原因是索引緩存區(qū)僅在所有insert語句完成后才刷新到磁盤上一次;
增加key_buffer_size值來擴大鍵高速緩沖區(qū)。
新聞標題:mysql服務(wù)器怎么加速 mysql服務(wù)器連接方式
轉(zhuǎn)載來于:http://www.chinadenli.net/article4/dddchie.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供微信小程序、面包屑導航、定制網(wǎng)站、商城網(wǎng)站、小程序開發(fā)、品牌網(wǎng)站制作
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)