mysql技術內幕之InnoDB Insert（插入）操作，mysqlinnodb

mysql技術內幕之InnoDB Insert（插入）操作，mysqlinnodb

當用戶端發出一條insert指令後，對於一張innodb類型的表，它的內部究竟會做出怎樣的反應呢？本文章將為大家揭開這 一內幕。當然，本人才疏學淺，如果你發現了什麼不對的地方，可以指出來，大家一起討論。

突然發現用文字很難解釋清楚這個過程，那麼就用一張圖來代替吧，反而更加清晰明了。我還沒有搞清楚的問題是：bin_log的寫入時間，commit操作對應redo跟innodb_buffer分別所處的位置。
以上內容是昨天，今天又有了新的發現，請自覺忽略忽略我在圖中沒有畫出binlog_buffer。。我想說的是，開啟事務之後，資料寫盤是在commit操作前還是在commit後，可能你會覺得這個問題很可笑，認為commit肯定是在資料寫磁碟之前，但是我接下來的實驗，可能會讓你改變這樣的想法。暫且做個假設：我們的innodb_buffer大小為1G，而一條insert操作，實際插入了2G的資料，你還確定寫磁碟操作是在commit之後嗎？實驗請看如下：

步驟如下：
1，開啟手動事務提交

mysql> show variables like’autocommit’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| autocommit | OFF |
+—————+——-+
1 row in set (0.00 sec)

2，建立test.test innodb表

mysql> create table test(id bigint ,salary bigint);
Query OK, 0 rows affected (0.05 sec)

3，查看錶空間初始值大小（原諒我手殘，剛開始調用了一次預存程序，沒有開啟手動提交，從12M開始算起）

rw-rw—- 1 mysql mysql 8590 7月 7 21:07 test.frm
-rw-rw—- 1 mysql mysql 12582912 7月 7 21:19 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 12M 7月 7 21:19 test.ibd
4，利用預存程序插入資料（虛擬機器，太慢，插了100W條，用了50秒）
mysql> call t(1000000);
Query OK, 1 row affected (50.94 sec)

5，查看錶空間大小情況（可以邊插邊看，好羞澀啊）

root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 12M 7月 7 21:19 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 44M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 44M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 44M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 48M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 48M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 48M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 48M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 48M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 52M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 52M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 52M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 52M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 54M 7月 7 21:21 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 60M 7月 7 21:36 test.ibd

好吧，資料表空間在不斷的增長。。怎麼解釋，我想唯一的解釋就是資料在commit操作前就已經開始寫入磁碟了。

我好奇的進行了rollback操作，看錶空間情況。整個100W條資料rollback的時間花了24.65秒。
+—————+——-+
1 row in set (0.00 sec)

mysql> rollback;
Query OK, 0 rows affected (24.65 sec)

緊接著，，查看錶空間大小

-rw-rw—- 1 mysql mysql 60M 7月 7 21:36 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 60M 7月 7 21:36 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 60M 7月 7 21:36 test.ibd

然而，資料表空間也沒有縮小。

搞技術的就是喜歡打破沙鍋問到底，我想再插一遍，看錶空間是否還會增大，

mysql> call t(1000000);
Query OK, 1 row affected (38.14 sec)

-rw-rw—- 1 mysql mysql 60M 7月 7 21:36 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 60M 7月 7 21:36 test.ibd
[root@ashe test]# ls -lh test.ibd
-rw-rw—- 1 mysql mysql 60M 7月 7 21:49 test.ibd
[root@ashe test]#

馬丹，，60M，我覺得我應該多看看innodb核心的資料了，甚至應該看一下它的源碼，去找尋心中的疑惑。

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。