熟悉mysql的人，都知道innodb儲存引擎，如大家所知，redo log是innodb的核心事務日誌之一，innodb寫入redo log後就會提交事務，而非寫入到datafile。之後innodb再非同步地將新事務的資料非同步地寫入datafile，真正儲存起來。
那麼innodb引擎有了redo log和buffer pool以後，為什麼能夠在提公升效能的同時，還能保證不丟資料呢? buffer pool, redo log以及datafile之間的具體關係是什麼呢。
另外innodb還有一大堆概念，dirty page, lru, lsn，checkpoint等等，這些概念在innodb裡是什麼運作的呢？
下面通過一張圖來告訴大家
buffer pool, redo log以及datafile的關係
大家可以把innodb的事務寫入過程看成寫作一篇文章的過程。innodb的寫入過程其實和我們寫作的過程是非常類似的。
試想，領導讓我們寫一篇文章，發表在論壇上。然後我們想到了乙個絕佳的點子，並決定要放到文章裡，可是手上還有其他事情，一時半會兒寫不完，又擔心過後忘了，領導還等著我們答覆，此時我們會怎麼做呢？我們一定會先大概構思個提綱，並把提綱和一些關鍵細節記錄到本子上，作為草稿，然後立刻告訴領導自己要寫什麼東西，讓其確認。最後等晚上有時間了，再根據草稿去斟詞酌句，編寫正稿。
在這個過程中，我們用到的幾個關鍵的東西：
我們的大腦，用來臨時暫時記住我們的點子
草稿，我們需要草稿來保證不會把點子和關鍵的細節給忘了
正稿，這是我們最終要輸出的東西
有了這幾個東西，我們不僅能確保我們不會錯過一篇漂亮的文章，還能快速告訴領導自己一定可以搞定這件事情。
innodb實際上也用到了這幾個關鍵的東西：
buffer pool：就是我們的大腦
事務日誌：就是我們的草稿
datafile：就是我們的正稿
只要按照之前寫文章的過程，來進行整個事務的寫入操作，不僅能保證不丟失資料，而且能夠快速響應。
一次寫入操作是一次事務，innodb首先把事務資料寫入到buffer pool和事務日誌中，也就是在大腦中記憶下來，並寫下草稿。然後就可以提交事務，響應客戶端了。之後innodb在「有時間的時候」，非同步地把這次寫入的資料從buffer pool，或者事務日誌中正式地寫入到datafile中，形成「正稿」。
其中，innodb為了保證事務日誌這個「草稿」一定能無損地還原成正稿，還不能占用太多空間，事務日誌需要有以下特點：
事務日誌中一定儲存了要寫入的所有資料內容
事務日誌只會把新事務追加在日誌最後，而不會去修改之前的內容
一旦事務資料被寫到datafile，事務日誌中的「草稿」就可以刪除了
通過上面3個特點我們可以看出，在形成「正稿」之前，「草稿」是不會被刪除的；同時，「草稿」的空間是可以被迴圈利用的；最後，只要「草稿」在，我們一定能寫出「正稿」。
這裡還需要說明的，是recovery流程。也就是如果在形成「正稿」前，資料庫crash了，我們需要重啟整個程序，伺服器，甚至只能把資料複製到另外一台伺服器來進行恢復。這個時候，事務日誌這個「草稿」就發揮了它最大的作用——資料恢復。這也和我們在工作生活中常出現的問題——把事情忘了——非常類似。
buffer pool本質就是儲存於記憶體中的乙個資料結構，記憶體和人的大腦一樣，是「健忘」的。資料庫crash時，buffer pool中的資料極大可能「灰飛煙滅」了。因此，事務日誌就如我們貼心的「記事本」，它把我們的記憶，儲存為「草稿」，當我們忘了的時候，就可以翻開，把記憶重新回想起來。
MYSQL資料庫引擎，ISAM和INNODB
其餘都屬於第二類，稱為 非事務安全型 non transaction safe 1 isam isam是乙個定義明確且歷經時間考驗的資料 管理方法，它在設計之時就考慮到資料庫被查詢的次數要遠大於更新的次數。因此，isam執行讀取操作的速度很快，而且不占用大量的記憶體和儲存資源。isam的兩個主要不足...
mysql修改資料庫的儲存引擎 InnoDB
檢視當前的儲存引擎 基本的差別 myisam型別不支援事務處理等高階處理，而innodb型別支援。myisam型別的表強調的是效能，其執行數度比innodb型別更快，但是不提供事務支援，而innodb提供事務支援以及外部鍵等高階資料庫功能。然後,一般我們的專案中設計的資料表是有外來鍵的.修改儲存引擎...
mysql修改資料庫的儲存引擎 InnoDB
目前例子是把引擎myisam修改為innodb 檢視當前資料庫的所支援的資料庫引擎以及預設資料庫引擎 資料庫支援的引擎和預設資料庫引擎 show engines 更改方式1 修改配置檔案my.cnf 開啟my.cnf，在 mysqld 最後新增為上default storage engine inn...