概述
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優化外，也要定期進行主機與資料庫空間的清理，時刻保持空間使用率相對比較低。當然告警的有效性也是高效手段之一。
mysql增加約束sql語句 sql語句新增約束
sql語句新增約束 主鍵約束 primary key constraint 要求主鍵列的資料唯一，並且不允許為空。唯一約束 unique constraint 要求該列唯一，允許為空，但只能出現乙個空值。檢查約束 check constraint 某列取值範圍限制 格式限制等，如有關年齡的約束。預設...
mysql增加約束sql語句 SQL語句新增約束
檢查資料庫是否存在 use master go if exists select from sysdatabases where drop database studentdb 建資料庫 create database studentdb on primary name student filena...
mysql動態sql語句
直接執行sql宣告 sqlstatement 例程 string mysql mysql create table employee emp id integer not null,dept id integer not null,emp fname char 10 not null,emp lna...