例項磁碟空間近1個月**趨勢明顯，主要是個別日誌表儲存較大且部分表存在空間碎片化的現象。
1、通過日常巡檢以及監控發現某例項磁碟空間近1月**趨勢明顯
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-9dlp06ur-1606120420027)( 「image.png」)]
2、在詢問業務方是否為正常的業務增長外，檢視該例項top表空間的表，排查是否存在異常較大的表
1）檢視資料儲存量較大的schema
select table_schema , round(sum((data_length + index_length + data_free) / 1024 / 1024), 2) as total_size from tables group by table_schema order by total_size desc;2）檢視具體schema下top表的空間使用情況
select table_schema, table_name , round(data_length / 1024 / 1024, 2) as data_size , round(index_length / 1024 / 1024, 2) as index_size , round(data_free / 1024 / 1024, 2) as free_size from tables where table_schema = 'db_rim' order by data_size desc limit 10;3、從以上截圖中我們可以得到資訊：db_rim庫庫下，rim_user_msg_log表的資料量很大，可檢視是否可對該表中無效的資料進行清理？rim_user_msg_analyse這張表的碎片化將盡17g，可考慮對這些碎片化空間進行**
4、最終採取的處理方法為：rim_user_msg_log表直接清空，rim_user_msg_analyse進行碎片化**
1）清理前
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-1u2xscl0-1606120420038)( 「image.png」)]
2）清理後
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-d2tdsmi2-1606120420041)( 「image.png」)]
3）例項磁碟空間使用趨勢
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-8yourq2y-1606120420042)( 「image.png」)]
2.1 問題描述
通過對top表資料量的監控，我們可以看到sys_rest_server_log的資料量已經達到7000w,除空間占用外，我們更關注的是該錶對資料庫帶來的效能隱患。若業務上或者人為不當的查詢該錶資料，其操作的資源消耗在一定程度上一定會對正常業務造成影響。
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-8qu07fdy-1606120420043)( 「image.png」)]
2.2 問題處理
1、該錶當前的表現主要有兩點，一點是某瞬時寫入量極大，另外一點是表日增可達到300w記錄數。對於資料庫而言這種表行為或業務設計是不合理的，我們需要搞清楚該錶究竟是用來記錄哪些資訊，業務設計是否合理？
通過觀察表資料以及與相關開發人員溝通，我們得知該錶會記錄應用端所有的介面呼叫資訊，我們所觀察到的資料增長尖峰也正是由於業務量**而導致該錶瞬間併發寫入大量日誌資訊。
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-5zrpi8my-1606120420044)( 「image.png」)]
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-wuue05mx-1606120420045)( 「image.png」)]
2、對於這種大資料量的日誌記錄資訊，建議最好使用elk這種日誌分析服務，而不是使用資料庫進行儲存
3、限於開發人員開發能力有限，無法改造業務架構。針對該錶日增長、瞬間增長都極大的情況，我們與開發人員溝通該錶記錄的資料是否可從源端上進行減少。只記錄重要資訊、非重要資訊的介面日誌入庫進行遮蔽
4、確定表資料記錄可從最根本減產後，我們仍需要對目前7000w的資料進行處理，將歷史無效資料進行清理，並制定合適的資料清理策略
5、無效歷史資料清理/資料清理策略
1、建立備份表： create table sys_rest_server_log_bak_0228_1 like sys_rest_server_log;
2、表名替換 將源表sys_rest_server_log重新命名為備份表，備份表sys_rest_server_log_bak_0208_1重新命名為源表sys_rest_server_log，業務資料會寫入空的新錶，但是在rename期間這部分業務日誌寫入會失敗【需關注】 rename table sys_rest_server_log to sys_rest_server_log_bak_0228_2,sys_rest_server_log_bak_0228_1 to sys_rest_server_log;
3、將備份表sys_rest_server_log_bak_0208_2中的仍然需要的資料重新寫入到sys_rest_server_log，分批次寫入，sys_rest_server_log保留近15天資料。程式上可保證主鍵fd_id唯一，避免主鍵衝突。 insert into sys_rest_server_log select * from sys_rest_server_log_bak_0228_2 where fd_start_time between '***' and '***';
4、調整平台資料清理策略，將服務執行日誌備份天數改為15天，清除服務執行日誌備份天數改為30天
5、sys_rest_server_log_bak_0228_2表保留80+天記錄資料，暫時可以不做清理，等程式維護的sys_rest_server_log_backup有完備的資料後，將sys_rest_server_log_bak_0228_2表清除；
optimize table tablename; alter table tablname engine=innodb;1、通過建立bak表與源表進行rename替換，rename期間會造成業務對該錶資料寫入失敗
2、bak表建立的時需關注primayr key
1）程式上保證主鍵唯一可不需要關注
2）若主鍵使用自增長，建議在建立bak表建立時提高當前的auto_increment指，空餘一部分buffer空間，保證後續將源表歷史資料寫入rename後的新錶時主鍵不衝突
3、對於此類經常需要進行資料清理的表，建議使用分割槽表進行儲存，後續對資料的處理僅僅需要刪除指定分割槽
mysql碎片空間 mysql碎片應用
1.查詢結果集中自增功能 set i 0 select i i 1 id 2.資料庫備份 mysqldump database uroot p beifen.sql 3.資料庫表空間tablespace優化 show table status from database like table nam...
Mysql優化碎片空間
mysql的表在使用的過程，會不斷產生碎片空間，占用儲存 1.查詢表的碎片空間 可以看到有120m左右的碎片空間 下面執行命令進行優化，表越大執行時間越長，執行過程中會鎖住表，切記在業務低峰操作 可以看到2g的資料，120m的碎片空整理用了8分鐘 此時再次檢視表空間使用情況 可以看到碎片空間被清理掉...
mysql 表空間碎片 MySQL 清除表空間碎片
碎片產生的原因 1 表的儲存會出現碎片化，每當刪除了一行內容，該段空間就會變為空白 被留空，而在一段時間內的大量刪除操作，會使這種留空的空間變得比儲存列表內容所使用的空間更大 2 當執行插入操作時，mysql會嘗試使用空白空間，但如果某個空白空間一直沒有被大小合適的資料占用，仍然無法將其徹底占用，就...