ibdata1和mysql-bin日志占用空間太多導致磁盤空間報警的解決辦法 。

　　首先分析問題原因：ibdata1為存儲類格式，而在INNODB的類型數據狀態下，ibdata1用來存儲文件的數據和索引，在庫名的文件夾里的那些表文件只是結構而已。innodb存儲引擎有兩種表空間的管理方式，分別是：

　　1）共享表空間，目前這個是各數據庫使用最多的方法；

　　2）獨立表空間，每一個表都會享有一個獨立的表空間；

　　當然，這兩種方式都有各自的優點和缺點：

　　優點：

　　共享表空間的優點是：能夠將表空間切成很多個文件存放到不同的磁盤上(表空間文件大小不受表大小的限制，一個表可以分布在不同步的文件上)。

　　獨立表空間的優點是：其對應的磁盤空間實可以被收回的。

　　缺點：

　　共享表空間的缺點是:數據和索引都全部存放在了一個文件里，但數據越來越大時，就將會有一個很大的文件，盡管可以將它分成多個小文件，但是多個表及索引在表空間中混合存儲，這樣如果對于一個表做了大量刪除操作后表空間中將有大量空隙。在共享表空間管理的方式下，如果表空間被分配，就不可能再回縮。若出現臨時建索引或是創建一個臨時表的操作表空間擴大后，就是刪除相關的表也沒辦法回縮那部分空間了。

　　獨立表空間的缺點：如果單表超過100G，則性能會受到影響。若用共享表空間把文件分開，但會出現的問題就是，如果訪問的范圍過大同樣會訪問多個文件。若使用獨立表空間，則考慮使用分區表的方法，可緩解問題。當啟用獨立表空間模式時，需要合理調整innodb_open_files參數的設置。

　　解決:

　　1）ibdata1數據太大：只可以通過dump，先導出建庫的sql語句，最后重新建立的方法。

　　2）mysql-bin Log太大有兩個解決辦法：

　　①手動刪除：

　　刪除某個日志：mysql>PURGE MASTER LOGS TO ‘mysql-bin.010′;

　　刪除某天前的日志：mysql>PURGE MASTER LOGS BEFORE ’2010-12-22  13:00:00′;

　　②在/etc/my.cnf里設置只保存N天的bin-log日志

　　expire_logs_days = 30  //Binary Log自動刪除的天數。