MySQL的InnoDB擴容及ibdata1文件瘦身計劃完整解析。本站提示廣大學習愛好者：（MySQL的InnoDB擴容及ibdata1文件瘦身計劃完整解析）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL的InnoDB擴容及ibdata1文件瘦身計劃完整解析正文
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失落。如許省些空間和時光
nd:url(valid.png) no-repeat 200px 5px #F0F0EF;
