概述

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

分析

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

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

查看監控

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

主機層面

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

數據庫層面

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

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

大量IO原因就是為了把數據從內存置換至磁盤產生的，而這批數據磁盤臨時表占用了大量空間，一旦SQL執行結束或終止，相應占用的空間就會立即釋放。

慢日志分析

分析相應時間段慢日志文件，發現以下SQL語句存在問題，消耗大量主機資源。

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

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

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

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

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

• 排序數據量大，導致排序過程中因內存有限而把數據轉換至磁盤，效率太低且短時間內占用大量空間。

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

總結

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。