資訊專欄INFORMATION COLUMN
收到短信告警，一生產庫空間使用率達到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優化外，也要定期進行主機與數據庫空間的清理，時刻保持空間使用率相對比較低。當然告警的有效性也是高效手段之一。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/130187.html
摘要：最近的互聯網線上事故發生比較頻繁，年月號順豐發生了一起線上刪庫事件，在這里就不介紹了。最后的最后，線上操作的任何一條命令，再小心也不為過，因為由于你的一個符號而引起的事故可能是你所承擔不起的。 摘要： 使用 Redis 的開發者必看，吸取教訓啊！ 原文：Redis 的 KEYS 命令引起 RDS 數據庫雪崩，RDS 發生兩次宕機，造成幾百萬的資金損失 作者：陳浩翔 Fundebu...
摘要：最近的互聯網線上事故發生比較頻繁，年月號順豐發生了一起線上刪庫事件，在這里就不介紹了。最后的最后，線上操作的任何一條命令，再小心也不為過，因為由于你的一個符號而引起的事故可能是你所承擔不起的。 摘要： 使用 Redis 的開發者必看，吸取教訓啊！ 原文：Redis 的 KEYS 命令引起 RDS 數據庫雪崩，RDS 發生兩次宕機，造成幾百萬的資金損失 作者：陳浩翔 Fundebu...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
