概述

MySQL數(shù)據(jù)庫由數(shù)據(jù)文件與各類日志文件組成，通常情況下，空間增長是由數(shù)據(jù)文件、binlog文件引起的，但個別情況下是短期內(nèi)MySQL產(chǎn)生了大量的磁盤臨時表引起的。本案例就是由低效sql產(chǎn)生了大量磁盤臨時表引起的。

分析

收到短信告警，一生產(chǎn)庫空間使用率達到90%，隨后登陸主機查看，發(fā)現(xiàn)空間使用率為45%，難道是誤告警？為了確認告警的真實性，查看該MySQL實例占用空間情況，數(shù)據(jù)文件占用空間不高，難道業(yè)務(wù)做數(shù)據(jù)刪除了？緊接著查看binlog文件占用情況，其占用空間也不高，而且該時間段產(chǎn)生的binlog比較少，真的是誤告警？查看監(jiān)控頁面：

空間使用率是達到過90%，不是誤告警，可隨后空間也立即釋放了。

查看監(jiān)控

登陸監(jiān)控平臺，查看主機空間使用率暴漲期間，主機及數(shù)據(jù)庫的性能情況和數(shù)據(jù)庫本身正在進行哪些操作。

主機層面

空間使用率暴漲期間，主機負載達到了40，較正常壓力值高出N多倍；cpu使用情況也較正常壓力值高出很多；IO已經(jīng)打滿，說明這段時間內(nèi)在進行大量的IO操作。

數(shù)據(jù)庫層面

數(shù)據(jù)庫活躍連接達到近40，也比平常高出很多，但數(shù)據(jù)庫每秒的請求量卻比平常低，說明數(shù)據(jù)庫此時處在阻塞狀態(tài)，等待后臺的大量IO操作完成。

數(shù)據(jù)庫會話都在進行數(shù)據(jù)排序操作，而SQL語句中排序字段選擇不合適，導(dǎo)致產(chǎn)生了大量臨時表，特別是因內(nèi)存放不下而置換至磁盤而產(chǎn)生的磁盤臨時表。

大量IO原因就是為了把數(shù)據(jù)從內(nèi)存置換至磁盤產(chǎn)生的，而這批數(shù)據(jù)磁盤臨時表占用了大量空間，一旦SQL執(zhí)行結(jié)束或終止，相應(yīng)占用的空間就會立即釋放。

慢日志分析

分析相應(yīng)時間段慢日志文件，發(fā)現(xiàn)以下SQL語句存在問題，消耗大量主機資源。

該SQL共運行154次，平均每次運行3981s，平均每次檢索24670000條記錄，平均每次返回2490000條記錄。

該SQL語句主要存在以下問題：

• 查詢時間字段上無索引。

• 查詢時間跨度太大，即使有索引也未必用的上。

• 排序字段過多且不合理。

• 排序數(shù)據(jù)量大，導(dǎo)致排序過程中因內(nèi)存有限而把數(shù)據(jù)轉(zhuǎn)換至磁盤，效率太低且短時間內(nèi)占用大量空間。

• 每次分頁查詢重復(fù)上次操作，且越靠后的分頁查詢，效率越低。

總結(jié)

數(shù)據(jù)庫臨時表的產(chǎn)生，特別是磁盤臨時表，如果短時間內(nèi)出現(xiàn)大量，導(dǎo)致主機空間使用率暴漲達到100%，那么相應(yīng)數(shù)據(jù)庫就會被hang住，無法再對外提供服務(wù)。在實際生產(chǎn)上避免此情況的發(fā)生，除了SQL優(yōu)化外，也要定期進行主機與數(shù)據(jù)庫空間的清理，時刻保持空間使用率相對比較低。當(dāng)然告警的有效性也是高效手段之一。

總結(jié)

以上是生活随笔為你收集整理的sql 2008日志增长过快_SQL语句引起的空间暴增分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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