在MYSQL5.5版本之后,具體是在5.58版本之后,InnoDB代替MYISAM稱為MYSQL的默認存儲引擎,說實話呢,是一個非常重要的事情,之前在使用MYSQL時,說別人使用InnoDB,而不用myisam,要費很多口舌,很多人會說,你說InnoDB這么好,那MYSQL為什么默認不用InnoDB呢,自從MYSQL把默認存儲引擎改成InnoDB以后呢,世界一下子就變得安靜了,至少給人解釋為什么MYSQL默認存儲引擎是MYISAM,而不是InnoDB就省了很多事情,另外MYSQL把默認引擎改成InnoDB,給那些不太了解MYSQL的管理人員呢,正確的使用存儲引擎提供了很大的幫助,因為默認存儲引擎就是適應大部分場景的存儲引擎了,和MYISAM不同的是,Innodb是一種事務型的存儲引擎,也就是說,Innodb是支持事務的ACID特性的,Innodb的設計更適合于大量的小事務,而事務呢,大部分情況下,會被正常的提交,很少的會被回滾,除了支持事務外,Innodb和myisam表,不同地方呢,還有在數據存儲方式上,也會不同,Innodb有自己的表空間的概念,是存儲在表空間之中的,具體存在什么樣的表空間之中呢,則由innnodb_file_per_table這個參數來決定,如果這個參數為ON,則會為每一個表建立ibd的擴展文件,如果這個參數為OFF型呢,則會把數據存儲到系統的共享表空間,也就是ibdataX中,這個X代表的是一個數字,它是從1開始的一個數字,我們可以到數據庫中看一下,兩種存儲的方式

看一下這兩種存儲的方式,首先我們回到我們的演示系統中,我們看一下剛才所提到的參數,系統中設置的值是什么,innodb_file_per_table,大家可以看到,這個系統中呢我們的innodb_per_table命令是打開的,所以他會為每一個表建立獨立的表空間,那下面我們來創建一個表

這個表就叫myinnodb好了,同樣只有兩列,一個是c1列,跟剛才的myisam表結構是一致的,這里我們還要查一下存儲引擎,innodb

現在這個表就已經建好了,我們來看一看他的文件系統是如何存儲的,我們來看一看所有innodb開頭的文件,大家可以看到,這里有一個frm文件,另一個就是ibd文件,這個frm文件呢,和myisam存儲引擎一樣,它是用于記錄表結構的,而另一個ibd文件呢,就是innodb表實際存儲的地方了

表實際存儲的這個地方了,下面我們再來看看如果這個Innodb的per_table設置為OFF的情況下,他又是如何存儲的呢,首先我們把參數設置成OFF,我們把它關掉set global innodb_file_per_table=off;

那么這個時候呢,看一下在當前進程下是否已經關閉了,那么，沒問題show variables like 'innodb_file_per_table';

我們再建立一個表,這個表家里innodb_g,id int,同樣表結構和上面是一樣的,我們看看這個表是如何存儲的create table myinnodb_g(id int,c1 varchar(10)) engine='innodb';

我們在同樣的位置來看一下,這個innodb_g這個表呢,我們的目錄中只有一個frm文件,而不存在ibd文件,他這個數據是存儲在系統共享表空間

也就是ibdata1中

下面就演示innodb是如何使用它的存儲表空間的,上面我們看到了innodb_file_per_table不同參數值,對innodb表數據存儲造成了不同的影響,那我們應該如何設置innodb_file_per_table這個參數呢,我們可以通過下面一些對比來搞明白這些問題,首先我們來比較一下系統文件對表空間的管理方式,在MYSQL5.6之前的innodb_file_per_table的默認值參數是OFF,也就是說,在MYSQL5.5版本的時候呢,默認使用的Innodb表,數據都會存儲到系統表空間中,如果還是有人認為默認的就是最合適的話,那么他可能會遇到下面的一些問題,在一個繁忙的系統中,它會發現系統表空間,在不斷的增長,這也沒有什么問題,只要沒有超過我們的磁盤限制呢,就是可以接受的,但是一旦我們的磁盤空間出現不足,我們為了釋放磁盤空間,不得不在系統中刪除大量的無效的數據,或者長期不會用到的日志類的數據,我們在刪除了數據后呢,系統表空間并不會縮小,另外在這種情況下,如果我們想通過復制文件的方式,對數據庫進行備份,由于雖然刪除了數據,表空間的大小并不會改變,這就意味著,我們每次刪除時,都要浪費很大的空間,不要以為我們不會遇到這種備份的問題,實際上目前最常用的innodb熱備的方式,是這樣處理的,因為這時候呢,就遇到了系統表空間,進行數據存儲的一些問題了,而想要收縮表空間的第一方法呢,把整個數據庫中的所有innodb表導出后,刪除innodb相關的表空間文件后,再重啟MYSQL,服務器進行表空間的重建,然后再導入出去,這個過程呢,實際上是很復雜的,并且十分耗時,這在業務繁忙的環境中呢,顯然是不可能做到的,所以我們如果使用系統表空間進行表數據的存儲,無法很容易的收縮系統文件,造成了大量的空間浪費,并且會產生大量的磁盤碎片,從而降低系統的性能,而如果我們使用獨立的表空間的話,這個問題就很好解決了,我們如果對一個大表的數據進行清理之后,可以很方便的對這一個表進行optimize table操作,這實際上也會對這個表進行重建,但是對比整個系統進行重建要快的多,而且不需要重啟數據庫服務器,甚至不會影響這個表的正常訪問,所以從這一點上來看,使用獨立表空間,顯然要比使用系統表空間要好得多

我們再來看看使用系統表空間和獨立表空間IO方面有哪些影響,對于系統表空間來說呢,由于只有一個文件,如果對多個表進行數據刷新時,實際上從系統文件上來說呢,順序進行的,所以會產生IO瓶頸,而對于獨立表空間來說呢,由于每一個表都有自己的獨立表空間文件,并且在進行數據寫入時呢,可以利用多個文件增加,增加IO處理的性能,所以對于頻繁寫入操作的系統來說呢,不太適合系統表空間統一存放數據,而是要使用獨立表空間的方式,通過以上對獨立表空間和系統表空間的對比,相信大家已經知道如何在這兩種表空間中進行選擇了

在這里強烈建議大家,對于Innodb存儲引擎呢,使用獨立的表空間進行管理,另外呢,在MYSQL5.6后,獨立表空間也成為了默認的配置,而對于以前使用的表空間,來進行管理的數據庫呢,如果想要轉成使用獨立表空間的話,就只能通過下面的步驟來進行處理了,我們來看如何把原來存在于系統表空間中的表轉移到獨立表空間中的方法,基本上可以分為4個步驟,首先第一步,我們需要使用mysqldump導出所有數據庫表的數據,這一步沒有什么好說的,要注意的就是呢,如果我們的數據庫中使用存儲過程,觸發器,一定要一起導出,接下來我們就要停止咱們的MYSQL服務器,當然呢如果是主從架構的服務的話,我們也可以先從從服務器上進行操作,停止MYSQL服務器之后呢,也需要修改my.conf配置文件,并加上innodb_file_per_table參數,刪除原來innodb表空間的相關文件,實際上我們以前把所有的表空間都備份出來了,所以這里重建了一個data目錄,第三步就是要重啟MYSQL服務,并重建Innodb系統表空間,這時候啟動表空間呢,已經不含有任何數據了,最后一步就是需要重新導入備份的數據,就可以完成數據的恢復,并且把開始存在表空間的數據呢,遷移到獨立的表空間中了,當然我們也可以不按上面的方法操作,比如我們還可以在修改完參數后,對每個表進行alter table操作,這樣也可以遷入到獨立表空間中,但是無法對系統表空間占用的磁盤空間進行回收,所以還是建議大家,按以上的方法來完成向系統表空間向獨立表空間的遷移

?

總結

以上是生活随笔為你收集整理的MySQL常用存储引擎之Innodb的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。