mysql的innodb擴容
為了添加一個數據文件到表空間中，首先要關閉 MySQL 數據庫，編輯 my.cnf 文件，確認innodb ibdata文件的實際情況和my.cnf的配置是否一致，這裡有兩種情況：
1.my.cnf的配置
innodb_data_file_path=ibdata1:10G;ibdata2:10G:autoextend
如果當前數據庫正在使用ibdata1，或者使用ibdata2，但ibdata2沒有超過10G，則對my.cnf配置直接改成：
innodb_data_file_path=ibdata1:10G;ibdata2:10G;ibdata3:10G:autoextend
2.如果設置了最後一個ibdata自動擴展時，有可能最後一個ibdata的占用空間大於my.cnf的配置空間。例如：
mysql@test:/data1/mysqldata/innodb/data> ls -lh
-rw-rw---- 1 mysql mysql 10737418240 2010-01-26 16:34 ibdata1 -rw-rw---- 1 mysql mysql 16106127360 2010-01-26 16:34 ibdata2
這時，需要精確的計算ibdata2的大小 15360M，修改：
innodb_data_file_path=ibdata1:10G;ibdata2:15360M;ibdata3:10G:autoextend
重啟mysql。
注意：
1、擴容前注意磁盤空間是否足夠。
2、restart後關注是否生成了新的ibdata。
更多說明：
如果，最後一個文件以關鍵字 autoextend 來描述，那麼編輯 my.cnf 的過程中，必須檢查最後一個文件的尺寸，並使它向下接近於 1024 * 1024 bytes (= 1 MB) 的倍數（比方說現在autoextend 的/ibdata/ibdata1為18.5M，而在舊的my.ini中為10M，則需要修改為innodb_data_file_path = /ibdata/ibdata1:19M; 且必須是19M，如果指定20M，就會報錯。），並在 innodb_data_file_path 中明確指定它的尺寸。然後你可以添加另一個數據文件。記住只有 innodb_data_file_path 中的最後一個文件可以被指定為 auto-extending。
一個例子：假設起先僅僅只有一個 auto-extending 數據文件 ibdata1 ，這個文件接近於 988 MB。下面是添加了另一個 auto-extending 數據文件後的可能示例 。
innodb_data_home_dir = innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
ibdata1 瘦身
0. ibdata1裡存了什麼
當你啟用了 innodb_file_per_table，表被存儲在他們自己的表空間裡，但是共享表空間仍然在存儲其它的 InnoDB 內部數據：
（1）數據字典，也就是 InnoDB 表的元數據
（2）變更緩沖區
（3）雙寫緩沖區
（4）撤銷日志
其中的一些在 Percona 服務器上可以被配置來避免增長過大的。例如你可以通過 innodb_ibuf_max_size 設置最大變更緩沖區，或設置 innodb_doublewrite_file 來將雙寫緩沖區存儲到一個分離的文件。
MySQL 5.6 版中你也可以創建外部的撤銷表空間，所以它們可以放到自己的文件來替代存儲到 ibdata1。
1. 什麼引起 ibdata1 增長迅速？
當 MySQL 出現問題通常我們需要執行的第一個命令是：
SHOW ENGINE INNODB STATUS/G
這將展示給我們一些很有價值的信息。我們從** TRANSACTION（事務）**部分開始檢查，然後我們會發現這個：
---TRANSACTION 36E, ACTIVE 1256288 sec MySQL thread id 42, OS thread handle 0x7f8baaccc700, query id 7900290 localhost root show engine innodb status Trx read view will not see trx with id >= 36F, sees < 36F
這是一個最常見的原因，一個14天前創建的相當老的事務。這個狀態是活動的，這意味著 InnoDB 已經創建了一個數據的快照，所以需要在撤銷日志中維護舊頁面，以保障數據庫的一致性視圖，直到事務開始。如果你的數據庫有大量的寫入任務，那就意味著存儲了大量的撤銷頁。
如果你找不到任何長時間運行的事務，你也可以監控INNODB STATUS 中的其他的變量，“History list length（歷史記錄列表長度）”展示了一些等待清除操作。這種情況下問題經常發生，因為清除線程（或者老版本的主線程）不能像這些記錄進來的速度一樣快地處理撤銷。
2. 我怎麼檢查什麼被存儲到了 ibdata1 裡了？
很不幸，MySQL 不提供查看什麼被存儲到 ibdata1 共享表空間的信息，但是有兩個工具將會很有幫助。第一個是馬克·卡拉漢制作的一個修改版 innochecksum ，它發布在這個漏洞報告裡。
它相當易於使用：
# ./innochecksum /var/lib/mysql/ibdata1 0 bad checksum 13 FIL_PAGE_INDEX 19272 FIL_PAGE_UNDO_LOG 230 FIL_PAGE_INODE 1 FIL_PAGE_IBUF_FREE_LIST 892 FIL_PAGE_TYPE_ALLOCATED 2 FIL_PAGE_IBUF_BITMAP 195 FIL_PAGE_TYPE_SYS 1 FIL_PAGE_TYPE_TRX_SYS 1 FIL_PAGE_TYPE_FSP_HDR 1 FIL_PAGE_TYPE_XDES 0 FIL_PAGE_TYPE_BLOB 0 FIL_PAGE_TYPE_ZBLOB 0 other 3 max index_id
全部的 20608 中有 19272 個撤銷日志頁。這占用了表空間的 93%。
第二個檢查表空間內容的方式是傑裡米·科爾制作的 InnoDB Ruby 工具。它是個檢查 InnoDB 的內部結構的更先進的工具。例如我們可以使用 space-summary 參數來得到每個頁面及其數據類型的列表。我們可以使用標准的 Unix 工具來統計撤銷日志頁的數量：
# innodb_space -f /var/lib/mysql/ibdata1 space-summary | grep UNDO_LOG | wc -l 19272
盡管這種特殊的情況下，innochedcksum 更快更容易使用，但是我推薦你使用傑裡米的工具去了解更多的 InnoDB 內部的數據分布及其內部結構。
好，現在我們知道問題所在了。
3. ibdata1 瘦身方案
其中的一些在 Percona 服務器上可以被配置來避免增長過大的。例如你可以通過 innodb_ibuf_max_size 設置最大變更緩沖區，或設置 innodb_doublewrite_file 來將雙寫緩沖區存儲到一個分離的文件。
MySQL 5.6 版中你也可以創建外部的撤銷表空間，所以它們可以放到自己的文件來替代存儲到 ibdata1。
通常不能移除 InnoDB 的數據文件。為了減小數據文件的大小，你必須使用 mysqldump 來轉儲(dump)所有的數據表，再重新建立一個新的數據庫，並將數據導入新的數據庫中。具體步驟如下：
（1）備份數據庫
mysqldump -uroot -p123456 --default-character-set=utf8 --opt --extended-insert=true --triggers -R --hex-blob --single-transaction --no-autocommit test > db_name.sql （2）停止數據庫
service mysqld stop
（3）刪除相關文件
ibdata1 ib_logfile* mysql-bin.index
（4）手動刪除除Mysql之外所有數據庫文件夾，然後啟動數據庫
service mysqld start
（5）還原數據
/usr/local/mysql/bin/mysql -uroot -phigkoo < /data/bkup/mysqldump.sql
主要是使用Mysqldump時的一些參數，建議在使用前看一個說明再操作。另外備份前可以先查看一下當前數據庫裡哪些表占用空間大，把一些不必要的給truncate table掉。這樣省些空間和時間
