MySQL InnoDB小結

前陣子一直在作與Mysql相關的項目，因而也一直在學習Mysql相關的知識，看了《Mysql:Innodb存儲引擎》、《高性能Mysql》後，也算對Mysql有必定的瞭解了，特意在此總結一下(圖片都是《Mysql:Innodb存儲引擎》電子版的)。 

mysql體系結構： 
       由：鏈接池組件、管理服務和工具組件、sql接口組件、查詢分析器組件、優化器組件、               
               緩衝組件、插件式存儲引擎、物理文件組成。 
       mysql是獨有的插件式體系結構，各個存儲引擎有本身的特色。         
       
       
  

       
mysql各個存儲引擎概述： 
        innodb存儲引擎：[/color][/b] 面向oltp(online transaction processing)、行鎖、支持外鍵、非鎖定讀、默認採用repeaable級別（可重複讀）經過next-keylocking策略避免幻讀、插入緩衝、二次寫、自適應哈希索引、預讀 
        myisam存儲引擎:   不支持事務、表鎖、全文索引、適合olap（在線分析處理），其中myd:放數據文件，myi:放索引文件 
        ndb存儲引擎：       集羣存儲引擎，share nothing，可提升可用性 
        memory存儲引擎：  數據存放在內存中，表鎖，併發性能差，默認使用哈希索引 
        archive存儲引擎：只支持insert和select zlib算法壓縮1：10，適合存儲歸檔數據如日誌等、行鎖 
        maria存儲引擎：   目的取代myisam、緩存數據和索引、行鎖、mvcc 
       
         
  

       
innodb特性： 
        主體系結構：默認7個後臺線程，4個io thread(insert buffer、log、read、write),1個master thread(優先級最高),1個鎖(lock)監控線程，1個錯誤監控線程。能夠經過show engine innodb status來查看。新版本已對默認的read thread和write thread分別增大到4個，可經過show variables like 'innodb_io_thread%'查看。 
        存儲引擎組成：緩衝池(buffer pool)、重作日誌緩衝池(redo log buffer)以及額外的內存池(additional memory pool).具體配置可由show variables like 'innodb_buffer_pool_size'、show variables like 
'innodb_log_buffer_size'、show variables like 'innodb_additional_mem_pool_size'來查看。 
        緩衝池：佔最大塊內存，用來存放各類數據的緩存包括有索引頁、數據頁、undo頁、插入緩衝、自適應哈希索引、innodb存儲的鎖信息、數據字典信息等。工做方式老是將數據庫文件按頁(每頁16k)讀取到緩衝池，而後按最近最少使用(lru)的算法來保留在緩衝池中的緩存數據。若是數據庫文件須要修改，老是首先修改在緩存池中的頁(發生修改後即爲髒頁)，而後再按照必定的頻率將緩衝池的髒頁刷新到文件。經過命令show engine innodb status;來查看。 
        日誌緩衝：將重作日誌信息先放入這個緩衝區，而後按必定頻率將其刷新到重作日誌文件。 
     



        master thread: 
       loop主循環每秒一次的操做： 
           日誌緩衝刷新到磁盤，即便這個事務尚未提交。(老是執行，因此再大的事務commit   
           的時間也是很快的)                       
           合併插入緩衝(innodb當前一秒發生的io次數小於5次則執行) 
           至多刷新100個innodb的緩衝池中的髒頁到磁盤(超過配置的髒頁所佔緩衝池比例則執 
           行，在配置文件中由innodb_max_dirty_pages_pac決定，默認是90，新版本是75， 
           google建議是80) 
           若是當前沒用用戶活動，切換到backgroud loop                 

       loop主循環每10秒一次的操做： 
           刷新100個髒頁到磁盤(過去10秒IO操做小於200次則執行) 
           合併至多5個插入緩衝(老是) 
           將日誌緩衝到磁盤(老是) 
           刪除無用的Undo頁(老是) 
           刷新100個或者10個髒頁到磁盤(有超過70%的髒頁，刷新100個髒頁;不然刷新10個髒頁) 
           產生一個檢查點 

       backgroud loop，若當前沒有用戶活動(數據庫空閒時)或者數據庫關閉時，就會切換到這個循環： 
           刪除無用的Undo頁(老是) 
           合併20個插入緩衝(老是) 
           跳回到主循環(老是) 
           不斷刷新100個頁，直到符合條件(可能在flush loop中完成) 

       若是flush loop中也沒有什麼事情能夠作了，InnoDB存儲引擎會切換到suspend_loop，將master thread掛起，等待事件的發生。若啓用了InnoDB存儲引擎，卻沒有使用任何InnoDB存儲引擎的表，那麼master thread老是處於掛起狀態 

        插入緩衝：不是緩衝池的一部分，Insert Buffer是物理頁的一個組成部分,它帶來InnoDB性能的提升。根據B+算法(下文會提到)的特色，插入數據的時候會主鍵索引是順序的，不會形成數據庫的隨機讀取，而對於非彙集索引(即輔助索引)，葉子節點的插入再也不是順序的了，這時須要離散地訪問非彙集索引，插入性能在這裏變低了。InnoDB引入插入緩衝，判斷非彙集索引頁是否在緩衝池中，若是在則直接插入;不在，則先放在 插入緩衝區中。而後根據上述master thread中介紹的，會有必定的頻率將插入緩衝合併。此外，輔助索引不能是惟一的，由於插入到插入緩衝時，並不去查找索引頁的狀況，不然仍然會形成隨機讀，失去插入緩衝的意義了。插入緩衝可能會佔緩衝池中內存，默認也能會佔到1/2，因此能夠將這個值調小點，到1/3。經過IBUF_POOL_SIZE_PER_MAX_SIZE來設置，2表示1/2,3表示1/3。 

        兩次寫：   它帶來InnoDB數據的可靠性。若是寫失效，能夠經過重作日誌進行恢復，可是重作日誌中記錄的是對頁的物理操做，若是頁自己損壞，再對其進行重作是沒有意義的。因此，在應用重作日誌前，須要一個頁的副本，當寫入失效發生時，先經過頁的副原本還原該頁，再進行重作，這就是doublewire。 
         恢復數據=頁副本+重作日誌 
                           
       
  

                           
      自適應哈希索引：InnoDB存儲引擎提出一種自適應哈希索引，存儲引擎會監控對錶上索引的查找，若是觀察到創建創建哈希索引會帶來速度的提高，則創建哈希索引，因此稱之爲自適應的。自適應哈希索引只能用來搜索等值的查詢，如select * from table where index_col='***', 此外自適應哈希是由InnoDB存儲引擎控制的，咱們只能經過innodb_adaptive_hash_index來禁用或啓用，默認開啓。 
                           
mysql 文件 
      參數文件：告訴Mysql實例啓動時在哪裏能夠找到數據庫文件，而且指定某些初始化參數，這些參數定義了某種內存結構的大小等設置。用文件存儲，可編輯，若啓動時加載不到則不能成功啓動（與其餘數據庫不一樣）。參數有動態和靜態之分，靜態至關於只讀，動態是能夠set的。如咱們經過show variable like '***'查出來的key、value值，是能夠經過set key=value直接修改的。同是，修改時還有做用域之分，即這個seesion個有效和全局有效，在對應的key前加上session或global便可，如select @@seesion.read_buffer_size、set @@global.read_buffer_size。 
      日誌文件：用來記錄Mysql實例對某種條件作出響應時寫入的文件。如錯誤日誌文件、二進制日誌文件、慢查詢日誌文件、查詢日誌文件等。 
      錯誤日誌：經過show variables like 'log_error'來查看錯誤日誌存放地址 
      慢查詢日誌：經過show variables like '%long%' 查看慢查詢日誌記錄的閾值，新版本設成了0.05；經過show variables like 'log_slow_queries'查看是否開啓了，默認爲關閉的；經過show variabes like 'log_queries_not_using_indexes'查看是將沒有使用索引的查詢記錄到慢日誌中。mysql中能夠直接經過mysqldumpslow命令來查看慢日誌。 
      二進制文件：不記錄查詢，只記錄對數據庫全部的修改操做。目的是爲了恢復(point-in-time修復)和複製。經過show variables like 'datadir'查看存放路徑。二進制日誌支持STATEMENT、ROW、MIX三種格式，經過binlog_format參數設定，一般設置爲ROW，能夠爲數據庫的恢復和複製帶來更好的可靠性，但會帶來二進制文件大小的增長，複製時會增長網絡開銷。mysql中經過mysqlbinlog查看二進制日誌文件內容。 
      socket文件：當用Unix域套接字方式進行鏈接時須要的文件。 
      pid文件：Mysql實例的進程ID文件。 
      Mysql表結構文件：用來存放Mysql表結構定義文件。由於Mysql插件式存儲引擎的體系結構，每一個表都有一個對應的文件，以frm後綴結尾。 
      存儲引擎文件：存儲本身的文件來保存各類數據，真正存儲了數據和索引等數據。下面主要介紹InnoDB的存儲引擎下的表空間文件和重作日誌文件。 
      表空間文件：InnoDB默認的表空間文件爲ibdata1,可經過show variables like 'innodb_file_per_table'查看每一個表是否產生單獨的.idb表空間文件。可是，單獨的表空間文件僅存儲該表的數據、索引和插入緩衝等信息，其他信息仍是存放在默認的表空間中。 

  


                             
        重作日誌文件：實例和介質失敗，重作日誌文件就能派上用場，如數據庫掉電，InnoDB存儲引擎會使用重作日誌恢復到掉電前的時刻，以此來保證數據的完整性。參數innodb_log_file_size指定了重作日誌文件的大小；innodb_log_file_in_group指定了日誌文件組中重作日誌文件的數量，默認爲2，innodb_mirrored_log_groups指定了日誌鏡像文件組的數量，默認爲1，表明只有一個日誌文件組，沒有鏡像；innodb_log_group_home_dir指定了日誌文件組所在路徑，默認在數據庫路徑下。 
         二進制日誌和重作日誌的區別：首先，二進制日誌會記錄全部與Mysql有關的日誌記錄，包括InnoDB、MyISAM、Heap等其餘存儲引擎的日誌。而InnoDB存儲引擎重作日誌只存儲有關其自己的事務日誌；其次內容不一樣，無論將二進制日誌文件記錄的格式設爲STATEMENT仍是ROW，又或者是MIXED，其記錄的都是關於一個事務的具體操做內容。而InnoDB存儲引擎的重作日誌文件記錄的關於每一個頁的更改的物理狀況 。此外，寫入時間不一樣，二進制日誌文件是在事務提交前進行記錄的，而在事務進行的過程當中，不斷有重作日誌條目被 寫入重作日誌文件中。 
         
mysql innodb表 
       表空間：表空間可看作是InnoDB存儲引擎邏輯結構的最高層。 
       段：表空間由各個段組成，常見的段有數據段、索引段、回滾段等。 
       區：由64個連續的頁組成，每一個頁大小爲16kb，即每一個區大小爲1MB。 
       頁：每頁16kb，且不能更改。常見的頁類型有：數據頁、Undo頁、系統頁、事務數據頁、插入緩衝位圖頁、插入緩衝空閒列表頁、未壓縮的二進制大對象頁、壓縮的二進制大對象頁。 
       行：InnoDB存儲引擎是面向行的(row-oriented)，每頁最多容許存放7992行數據。 
       行記錄格式：常見兩種行記錄格式Compact和Redundant，mysql5.1版本後，主要是Compact行記錄格式。對於Compact，無論是char型仍是varchar型，null型都是不佔用存儲空間的；對於Redudant,varchar的null不佔用空間，char的null型是佔用存儲空間的。 
         varchar類型的長度限制是65535，其實達不到，會有別的開銷，通常是65530左右，這還跟選取的字符集有關。此外這個長度限制是一整行的，例如：create table test(a varchar(22000), b varchar(22000), cvarchar(22000)) charset=latin1 engine=innodb也會報錯。 
                         
         對於blob類型的數據，在數據頁面中只保存了varchar(65535)的前768個字節前綴數據，以後跟的是偏移量，指向行溢出頁，也就是Uncompressed BLOB Page。新的InnoDB Plugin引入了新的文件格式稱爲Barracuda，其有兩種新的行記錄格式Compressed和Dynamic，二者對於存入Blog字段採用了徹底溢出的方式，在數據庫頁中存放20個字節的指針，實際的數據都存入在BLOB Page中。 
                               
  

  


        數據頁結構：數據頁結構由如下7個部分組成： 
             File Header(文件頭):記錄頁的一些頭信息，如頁偏移量、上一頁、下一頁、頁類型等，固定長度爲38個字節。 
             Page Header(頁頭)：記錄頁的狀態信息，堆中記錄數、指向空閒列表的指針、已刪除記錄的字節數、最後插入的位置等，固定長度共56個字節。 
             Infimun+Supremum Records:在InnoDB存儲引擎中，每一個數據頁中有兩個虛擬的行記錄，用來限定記錄的邊界。 
             Infimun記錄是比該頁中任何主鍵都要小的值，Supermum指比任何可能大的值還要大的值。這兩個值在頁建立時被創建，而且在任何狀況下不會被刪除。在Compact行格式和Redundant行格式下，二者佔用的字節數各不相同。 
               
 
                                                           
               User Records(用戶記錄，即行記錄):實現記錄的內容。再次強調，InnoDB存儲引擎表老是B+村索引組織的。
               Free Space(空閒空間)：指空閒空間，一樣也是個鏈表數據結構。當一條記錄被刪除後，該空間會被加入空閒鏈 表中。 
               Page Directory(頁目錄)：頁目錄存放了記錄的相對位置，並非偏移量，有些時候這些記錄稱爲Slots(槽)，InnoDB並非每一個記錄一個槽，槽是一個稀疏目錄，即一個槽中可能屬於多個記錄，最少屬於4條記錄，最多屬於8條記錄。須要牢記的是，B+樹索引自己並不能找到具體的一條記錄，B+樹索引能找到只是該記錄所在的頁。數據庫把頁載入內存，而後經過Page Directory再進行二叉查找。只不過二叉查找的時間複雜度低，同時內存中的查找很快，所以經過忽略了這部分查找所用的時間。 
                 File Trailer(文件結尾信息)：爲了保證頁完整地寫入磁盤(如寫過程的磁盤損壞、機器宕機等)，固定長8個字節。                                                                                   

        視圖：Mysql中的視圖老是虛擬的表，自己不支持物化視圖。可是經過一些其餘技巧(如觸發器)，一樣也能夠實現一些簡單的物化視圖的功能。 

        分區：Mysql數據庫支持RANGE、LIST、HASH、KEY、COLUMNS分區，而且可使用HASH或KEY來進行子分區。 
                     
mysql innodb常見索引與算法： 
      B+樹索引：B+樹的數據結構相對較複雜，B表明的是balance最先是從平衡二叉樹演化而來，但B+樹並非一個二叉樹，對其較詳細的介紹能夠參見這篇文章：http://blog.csdn.net/v_JULY_v/article/details/6530142 因爲B+樹索引的高扇出性，所以在數據庫中，B+樹的高度通常都在2~3層，也就對於查找某一鍵值的行記錄，最多隻要2到3次IO,如今通常的磁盤每秒至少能夠作100次IO，2~3次的IO意味着查詢時間只需0.02~0.03秒。 
     數據庫中的B+索引能夠分爲彙集索引(clustered index)和輔助彙集索引(secondary index),但其內部都是B+樹的，即高度平衡的，葉子節點存放數據。 
      彙集索引：因爲彙集索引是按照主鍵組織的，因此每一張表只能有一個彙集索引，每一個數據頁都經過雙向鏈表進行鏈接，葉子節點存放一整行的信息，因此查詢優化器更傾向走彙集索引。此外，對於彙集索引的存儲是邏輯上連續的。因此，彙集索引對於主鍵的排序查找和範圍查找速度很是快。 
      輔助索引：也叫非彙集索引，葉子節點不存所有數據，主要存鍵值及一個boomark(其實就是彙集索引的鍵)告訴InnoDB哪裏能夠找到與索引相對應的行數據，如一個高度爲3的輔助索引和一個高度爲3的彙集索引，若根據輔助索引來查詢行記錄，一共須要6次IO。另外輔助索引能夠有多個。 
                       
          索引的使用原則：高選擇、取出表中的少部分數據(也稱爲惟一索引)。通常取出的數據量超過表中數據的20%，優化器不會使用索引，而進行全表掃描。如對於性別等字段是沒有意義的。 
          聯合索引： 也稱複合索引，是在多列（>=2）上創建的索引。Innodb中的複合索引也是b+ tree結構。索引的數據包含多列(col1, col2, col3…)，在索引中依次按照col1, col2, col3排序。如(1, 2), (1, 3),(2,0)…使用複合索引要充分利用最左前綴原則，顧名思義，就是最左優先。如建立索引ind_col1_col2(col1, col2)，那麼在查詢where col1 = xxx and col2 = xx或者where col1 = xxx均可以走ind_col1_col2索引，但where col2=****是走不到索引的。在建立多列索引時，要根據業務需求，where子句中使用最頻繁且過濾效果好的的一列放在最左邊。 
                           
        哈希索引：哈希算法也是比較常見的算法，mysql innoDB中使用了比較常見的鏈地址法進行去重。此外上面已經說起，innoDB中的hash是自適應的，何時使用hash是系統決定的，沒法進行人工設置。 
        二分查找法：這個算法比較常見，這裏就很少說起了。在InnoDB中，每頁Page Directory中的槽是按照主鍵的順序存放的，對於某一條具體記錄的查詢是經過對Page Directory進行二分查找獲得的。 

mysql innodb中的鎖 
         InnoDB存儲引擎鎖的實現和Oracle很是相似，提供一致性的非鎖定讀、行級鎖支持、行級鎖沒有相關的開銷，能夠同時獲得併發性和一致性。 
         InnoDB存儲引擎實現了以下兩種標準的行級鎖： 
          共享鎖(S Lock)：容許事務讀一行數據； 
          排他鎖(X Lock)：容許事務刪除或者更新一行數據。 
         當一個事務已經得到了行r的共享鎖，那麼另外的事務能夠當即得到行r的共享鎖，由於讀取沒有改變行r的數據，咱們稱這種狀況爲鎖兼容。但若是有事務想得到行r的排他鎖，則它必須等待事務釋放行r上的共享鎖————這種狀況稱爲鎖不兼容。 
         


         在InnoDB Plugin以前，只能經過SHOW FULL PROCESSLIST，SHOW ENGINE INOODB STATUS等命令來查看當前的數據庫請求，而後再判斷當前事務中的鎖的狀況。新版本的InnoDB Plugin中，在INFORMATION_SCHEMA架構下添加了INNODB_TRX、INNODB_LOCKS、InnoDB_LOCK_WAITS。經過這三張表，能夠更簡單地監控當前的事務並分析可能存在的鎖的問題。 
          INNODB_TRX由8個字段組成： 
         trx_id:InnoDB存儲引擎內部惟一的事務ID 
         trx_state:當前事務的狀態。 
         trx_started:事務的開始時間。 
         trx_requested_lock_id:等待事務的鎖ID。如trx_state的狀態爲LOCK WAIT,那麼該值表明當前的等待以前事務佔用鎖資源的ID. 
         若trx_state不是LOCK WAIT,則該值爲NULL。 
         trx_wait_started:事務等待開始的時間。 
         trx_weight:事務的權重，反映了一個事務修改和鎖住的行數。在InnoDB存儲引擎中，當發生死鎖須要回滾時，InnoDB存儲會選 
         擇該值最小的進行回滾。 
         trx_mysql_thread_id:Mysql中的線程ID,SHOW PROCESSLIST顯示的結果。 
         trx_query:事務運行的sql語句。 
         經過select * from infomation_schema.INNODB_TRX;可查看 
         
          INNODB_LOCKS表，該表由以下字段組成： 
         lock_id:鎖的ID。 
         lock_trx_id:事務ID。 
         lock_mode:鎖的模式。 
         lock_type:鎖的類型，表鎖仍是行鎖。 
         lock_table:要加鎖的表。 
         lock_index:鎖的索引。 
         lock_space:InnoDB存儲引擎表空間的ID號。 
         lock_page:被鎖住的頁的數量。如果表鎖，則該值爲NULL。 
         lock_rec:被鎖住的行的數量。如果表鎖，則該值爲NULL。 
         lock_data:被鎖住的行的主鍵值。當是表鎖時，該值爲NULL。 
         經過select * from information_schema.INNODB_LOCK;可查看 
         
          INNODB_LOCK_WAIT由4個字段組成： 
         requesting_trx_id:申請鎖資源的事務ID。 
         requesting_lock_id:申請的鎖的ID。 
         blocking_trx_id:阻塞的鎖的ID。 
         經過select * from information_schema.INNODB_LOCK_WAITS;可查看。 
         
          一致性的非鎖定讀：InnoDB存儲引擎經過行多版本控制的方式來讀取當前執行時間數據庫中行的數據。若是讀取的行正在執行Delete、update操做，這時讀取操做不會所以而會等待行上鎖的釋放，相反，InnoDB存儲引擎會去讀取行的一個快照數據。快照數據是指該行以前版本的數據，該實現是經過Undo段來實現。而Undo用來事務中回滾數據，所以快照自己是沒有額外開銷的。此外，快照數據是不須要上鎖的，由於沒有必要對歷史的數據進行修改。一個行可能有不止一個快照數據，因此稱這種技術爲行多版本技術。由此帶來併發控制，稱之爲多版本併發控制(Multi VersionConcurrency Control, MVCC)。 
         事務的隔離級別：Read uncommitted、Read committed、Repeatable read、serializable。在Read Committed和Repeatable Read下，InnoDB存儲引擎使用非鎖定一致性讀。然而，對於快照的定義卻不一樣。在Read Committed事務隔離級別下，對於快照數據，非一致性讀老是讀取被鎖定行的最新一份快照數據。在Repeatable事務隔離級別下，對於快照數據，非一致性讀老是讀取事務開始時的行數據版本。                                   

  
                                                             

          鎖的算法： 
         Record Lock:單行記錄上的鎖 
         Gap Lock:間隙鎖，鎖定一個範圍，但不包含記錄自己 
         Next-Key Lock:Gap Lock + Record Lock，鎖定一個範圍，而且鎖定記錄自己。更加詳細的介紹能夠參見這篇blog,http://www.db110.com/?p=1848 

          鎖的問題： 
             丟失更新：經典的數據庫問題，當兩個或多個事務選擇同一行，而後基於最初選定的值更新該行時，會發生丟失更新問題。每一個事務都不知道其它事務的存在。最後的更新將重寫由其它事務所作的更新，這將致使數據丟失。 　　 
                 例: 
                         事務A和事務B同時修改某行的值， 
                           1.事務A將數值改成1並提交 
                           2.事務B將數值改成2並提交。 
                           這時數據的值爲2，事務A所作的更新將會丟失。 
                           解決辦法：事務並行變串行操做，對更新操做加排他鎖。 

               髒讀：一個事務讀到另外一個事務未提交的更新數據，即讀到髒數據。 
                   例: 
                           1.Mary的原工資爲1000, 財務人員將Mary的工資改成了8000(但未提交事務)               
                           2.Mary讀取本身的工資 ,發現本身的工資變爲了8000，歡天喜地！ 
                           3.而財務發現操做有誤，回滾了事務,Mary的工資又變爲了1000, 像這樣,Mary記取的工資數8000是一個髒數據。 
                           解決辦法：髒讀只有在事務隔離級別是Read Uncommitted的狀況下才會出現，innoDB默認隔離級別是Repeatable Read，因此生產環境下不會出現髒讀。 
                               
               不可重複讀：在同一個事務中,屢次讀取同一數據,返回的結果有所不一樣。換句話說就是,後續讀取能夠讀到另外一個事務已提交的更新數據。相反"可重複讀"在同一事務屢次讀取數據時,可以保證所讀數據同樣,也就是後續讀取不能讀到另外一事務已提交的更新數據。髒讀和不可重複讀的主要區別在於，髒讀是讀到未提交的數據，不可重複讀是讀到已提交的數據。 
                   例: 
                           1.在事務1中，Mary 讀取了本身的工資爲1000,操做並無完成 
                           2.在事務2中，這時財務人員修改了Mary的工資爲2000,並提交了事務. 
                           3.在事務1中，Mary 再次讀取本身的工資時，工資變爲了2000 
                           解決辦法：讀到已提交的數據，通常數據庫是可接受的，所以事務隔離級別通常設爲Read Committed。Mysql InnoDB經過Next-Key Lock算法避免不可重複讀，默認隔離級別爲Repeatable Read。 
         
         
mysql innodb中的事務       
         事務的四個特性：原子性、一致性、隔離性、持久性 
         隔離性經過鎖實現，原子性、一致性、持久性經過數據庫的redo和undo來完成。 
         重作日誌記錄了事務的行爲，經過redo實現，保證了事務的完整性，但事務有時還須要撤銷，這時就須要產生undo。undo和redo正好相反，對於數據庫進行修改時，數據庫不但會產生redo，並且還會產生必定的undo，即便執行的事務或語句因爲某種緣由失敗了，或者若是用一條rollback語句請求回滾，就能夠用這些undo信息將數據回滾到修改以前的樣子。與redo不一樣的是,redo存放在重作日誌文件中，undo存放在數據庫內部的一個特殊段(segment)中，這稱爲undo段(undo segment)，undo段位於共享表空間內。還有一點重要的是，undo記錄的是與事務操做相反的邏輯操做，如insert undo 記錄一個delete，因此undo只是邏輯地將數據庫恢復成事務開始前的樣子。如:insert 10萬行的數據，可能致使表空間增大，回滾後，表空間不會減少回去。 

版權聲明：QQ:597507041