1. 程式人生 > >InnoDB與MyIsAM鎖問題

InnoDB與MyIsAM鎖問題

  1. MyIsAM與InnoDB特點比較
MyIsAM   InnoDB
儲存限制無限制    64TB   
鎖機制   表鎖行鎖、表鎖
B樹索引 是   
Hash索引
全文索引支援
叢集索引不支援支援
資料可壓縮   支援不支援
空間使用率低   
記憶體使用率

批量插入速度   
外來鍵不支援支援
事務安全    不支援支援
表鎖:開銷小、加鎖快、不會出現死鎖、鎖的粒度大、發生鎖衝突的概率大、併發性低

行鎖:開銷大、加鎖慢、會出現死鎖、鎖的粒度小、衝突的發生概率更低、併發性更好。

InnoDB:支援事務,行鎖,B樹索引、叢集索引、支援外來鍵、批量插入資料慢,資料可壓縮MyIsAM:不支援事務,表鎖、B樹索引、全文索引、不支援外來鍵、批量插入較快,資料不可壓縮
  1. Hash索引優勢:Hash 索引結構的特殊性,其檢索效率非常高,索引的檢索可以一次定位,不像B-Tree 索引需要從根節點到枝節點,最後才能訪問到頁節點這樣多次的IO訪問,所以 Hash 索引的查詢效率要遠高於 B-Tree 索引。


  2. Hash索引不足:
    1)Hash 索引僅僅能滿足"=","IN"和"<=>"查詢,不能使用範圍查詢。(B樹可以查詢區間) 
         由於 Hash 索引比較的是進行 Hash 運算之後的 Hash 值,所以它只能用於等值的過濾,不能用於基於範圍的過濾,因為經過相應的 Hash 演算法處理之後的 Hash 值的大小關係,並不能保證和Hash運算前完全一樣。

    (2)Hash 索引無法被用來避免資料的排序操作。 
         由於 Hash 索引中存放的是經過 Hash 計算之後的 Hash 值,而且Hash值的大小關係並不一定和 Hash 運算前的鍵值完全一樣,所以資料庫無法利用索引的資料來避免任何排序運算;

    (3)Hash 索引不能利用部分索引鍵查詢。 
         對於組合索引,Hash 索引在計算 Hash 值的時候是組合索引鍵合併後再一起計算 Hash 值,而不是單獨計算 Hash 值,所以通過組合索引的前面一個或幾個索引鍵進行查詢的時候,Hash 索引也無法被利用。

    (4)Hash 索引在任何時候都不能避免表掃描。 
         前面已經知道,Hash 索引是將索引鍵通過 Hash 運算之後,將 Hash運算結果的 Hash 值和所對應的行指標資訊存放於一個 Hash 表中,由於不同索引鍵存在相同 Hash 值,所以即使取滿足某個 Hash 鍵值的資料的記錄條數,也無法從 Hash 索引中直接完成查詢,還是要通過訪問表中的實際資料進行相應的比較,並得到相應的結果。

    (5)Hash 索引遇到大量Hash值相等的情況後效能並不一定就會比B-Tree索引高。 
         對於選擇性比較低的索引鍵,如果建立 Hash 索引,那麼將會存在大量記錄指標資訊存於同一個 Hash 值相關聯。這樣要定位某一條記錄時就會非常麻煩,會浪費多次表資料的訪問,而造成整體效能低下。

事務:用於保證資料的一致性和完整性

原子性(Atom):操作要麼全部完成,要麼全部不執行。即:不存在有部分完成。保證資料一致性

一致性:事務操作前的狀態和事務提交以後的狀態可見,事務操作的中間狀態不可見。

隔離性:事務的操作相互獨立,不受其他事務的影響

永續性:事務提交完成後,資料操作寫入物理磁碟儲存。

引擎的選取:

MyIsAm:訪問速度快,若無事務要求,則可首選。

InnoDB:對事務完整性要求。

資料庫資料型別的比較:

  1. MySQL中varchar與char的區別以及varchar(50)中的50代表的涵義
(1)、varchar與char的區別
char是一種固定長度的型別,varchar則是一種可變長度的型別
(2)、varchar(50)中50的涵義
最多存放50個字元,varchar(50)和(200)儲存hello所佔空間一樣,但後者在排序時會消耗更多記憶體,因為order by col採用fixed_length計算col長度(memory引擎也一樣)
(3)、int(20)中20的涵義
是指顯示字元的長度
但要加引數的,最大為255,比如它是記錄行數的id,插入10筆資料,它就顯示00000000001 ~~~00000000010,當字元的位數超過11,它也只顯示11位,如果你沒有加那個讓它未滿11位就前面加0的引數,它不會在前面加0
20表示最大顯示寬度為20,但仍佔4位元組儲存,儲存範圍不變;
(4)、mysql為什麼這麼設計
對大多數應用沒有意義,只是規定一些工具用來顯示字元的個數;int(1)和int(20)儲存和計算均一樣;

2.text和BLOB

相同:都用於儲存大量的資料

不同:BLOB可用於儲存二進位制資料流、例如儲存圖片

3.浮點數和定點數

精度問題:浮點數超過精度,進行四捨五入,定點數:超過精度報錯,精度更高。

3.date、datetime、TimeStamp和year

檢視:

資料庫中存在的虛擬表,邏輯存在,通過封裝特定的sql,獲取特定的資料。

特點:

  1. 簡單:使用者不需要了解資料庫的表結構,呼叫特定的試圖即可獲取想要的資料
  2. 安全:使用檢視的使用者,只能訪問被允許的檢視
  3. 資料獨立:改變表結構(新增欄位),不影響檢視資料

儲存過程與函式:

儲存過程:完成特定功能的SQL語句集,可簡化開發,提高資料的處理效率

函式:完成特定的功能,但需要返回值,儲存過程不需要

1、什麼是事務

事務是一條或多條資料庫操作語句的組合,具備ACID,4個特點。

原子性:要不全部成功,要不全部撤銷

隔離性:事務之間相互獨立,互不干擾

一致性:資料庫正確地改變狀態後,資料庫的一致性約束沒有被破壞

永續性:事務的提交結果,將持久儲存在資料庫中

2、事務併發會產生什麼問題

1)第一類丟失更新:在沒有事務隔離的情況下,兩個事務都同時更新一行資料,但是第二個事務卻中途失敗退出, 導致對資料的兩個修改都失效了。

例如:

       張三的工資為5000,事務A中獲取工資為5000,事務B獲取工資為5000,匯入100,並提交資料庫,工資變為5100,

       隨後

       事務A發生異常,回滾了,恢復張三的工資為5000,這樣就導致事務B的更新丟失了。

2)髒讀:髒讀就是指當一個事務正在訪問資料,並且對資料進行了修改,而這種修改還沒有提交到資料庫中,這時,另外一個事務也訪問這個資料,然後使用了這個資料。
例如:
  張三的工資為5000,事務A中把他的工資改為8000,但事務A尚未提交。
  與此同時,
  事務B正在讀取張三的工資,讀取到張三的工資為8000。
  隨後,
  事務A發生異常,而回滾了事務。張三的工資又回滾為5000。
  最後,
  事務B讀取到的張三工資為8000的資料即為髒資料,事務B做了一次髒讀。

3)不可重複讀:是指在一個事務內,多次讀同一資料。在這個事務還沒有結束時,另外一個事務也訪問該同一資料。那麼,在第一個事務中的兩次讀資料之間,由於第二個事務的修改,那麼第一個事務兩次讀到的的資料可能是不一樣的。這樣就發生了在一個事務內兩次讀到的資料是不一樣的,因此稱為是不可重複讀。
例如:
  在事務A中,讀取到張三的工資為5000,操作沒有完成,事務還沒提交。
  與此同時,
  事務B把張三的工資改為8000,並提交了事務。
  隨後,
  在事務A中,再次讀取張三的工資,此時工資變為8000。在一個事務中前後兩次讀取的結果並不致,導致了不可重複讀。

4)第二類丟失更新:不可重複讀的特例。有兩個併發事務同時讀取同一行資料,然後其中一個對它進行修改提交,而另一個也進行了修改提交。這就會造成第一次寫操作失效。 

例如:

在事務A中,讀取到張三的存款為5000,操作沒有完成,事務還沒提交。
  與此同時,
  事務B,儲存1000,把張三的存款改為6000,並提交了事務。
  隨後,
  在事務A中,儲存500,把張三的存款改為5500,並提交了事務,這樣事務A的更新覆蓋了事務B的更新。

5)幻讀:是指當事務不是獨立執行時發生的一種現象,例如第一個事務對一個表中的資料進行了修改,這種修改涉及到表中的全部資料行。同時,第二個事務也修改這個表中的資料,這種修改是向表中插入一行新資料。那麼,以後就會發生操作第一個事務的使用者發現表中還有沒有修改的資料行,就好象發生了幻覺一樣。
例如:
  目前工資為5000的員工有10人,事務A讀取所有工資為5000的人數為10人。
  此時,
  事務B插入一條工資也為5000的記錄。
  這是,事務A再次讀取工資為5000的員工,記錄為11人。此時產生了幻讀。

提醒:
不可重複讀的重點是修改,同樣的條件,你讀取過的資料,再次讀取出來發現值不一樣了
幻讀的重點在於新增或者刪除,同樣的條件,第 1 次和第 2 次讀出來的記錄數不一樣

3、事務隔離級別,解決什麼併發問題,以及存在什麼併發問題

(1)READ_UNCOMMITTED
  這是事務最低的隔離級別,它充許另外一個事務可以看到這個事務未提交的資料。
  解決第一類丟失更新的問題,但是會出現髒讀、不可重複讀、第二類丟失更新的問題,幻讀 。
(2)READ_COMMITTED
  保證一個事務修改的資料提交後才能被另外一個事務讀取,即另外一個事務不能讀取該事務未提交的資料。
  解決第一類丟失更新和髒讀的問題,但會出現不可重複讀、第二類丟失更新的問題,幻讀問題
(3)REPEATABLE_READ
  保證一個事務相同條件下前後兩次獲取的資料是一致的

       解決第一類丟失更新,髒讀、不可重複讀、第二類丟失更新的問題,但會出幻讀。
(4)SERIALIZABLE
  事務被處理為順序執行。
  解決所有問題

提醒:

Mysql預設的事務隔離級別為repeatable_read

4、MyIsAm引擎的鎖機制

共享鎖:可同時讀、讀的同時不能寫

獨佔鎖:寫的同時不能讀和寫

如何加鎖:

select前,對所有涉及的表自動加共享鎖

更新資料時,加獨佔寫鎖

MyIsAM支援併發插入:讀的時候插入,但是插入的資料當前事務無法讀取

設定引數concurrent_Insert

0:不允許併發插入,1:無空洞,允許併發插入,2:有無都允許併發插入

空洞:刪除記錄造成

5、InnoDB引擎的鎖機制

(之所以以InnoDB為主介紹鎖,是因為InnoDB支援事務,支援行鎖和表鎖用的比較多,Myisam不支援事務,只支援表鎖)

共享鎖(S):允許一個事務去讀一行,阻止其他事務獲得相同資料集的排他鎖。
排他鎖(X):允許獲得排他鎖的事務更新資料,阻止其他事務取得相同資料集的共享讀鎖和排他寫鎖。
意向共享鎖(IS):事務打算給資料行加行共享鎖,事務在給一個數據行加共享鎖前必須先取得該表的IS鎖。
意向排他鎖(IX):事務打算給資料行加行排他鎖,事務在給一個數據行加排他鎖前必須先取得該表的IX鎖。

說明:

1)共享鎖和排他鎖都是行鎖,意向鎖都是表鎖,應用中我們只會使用到共享鎖和排他鎖,意向鎖是mysql內部使用的,不需要使用者干預。

2)對於UPDATE、DELETE和INSERT語句,InnoDB會自動給涉及資料集加排他鎖(X);對於普通SELECT語句,InnoDB不會加任何鎖,事務可以通過以下語句顯示給記錄集加共享鎖或排他鎖。
共享鎖(S):SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。
排他鎖(X):SELECT * FROM table_name WHERE ... FOR UPDATE。

3)InnoDB行鎖是通過給索引上的索引項加鎖來實現的,因此InnoDB這種行鎖實現特點意味著:只有通過索引條件檢索資料,InnoDB才使用行級鎖,否則,InnoDB將使用表鎖!。


相關推薦

InnoDBMyIsAM問題

MyIsAM與InnoDB特點比較MyIsAM   InnoDB儲存限制無限制    64TB   鎖機制   表鎖行鎖、表鎖B樹索引 是   是Hash索引全文索引支援叢集索引不支援支援資料可壓縮   支援不支援空間使用率低   高記憶體使用率低高批量插入速度   高低外來

MySql中啟用InnoDB數據引擎簡介 以及 InnoDB MYISAM的區別和聯系

隔離級別 最終 全文索引 都是 後臺 isa llb ldb 優勢 1、存儲引擎是什麽?   MySQL中的數據用各種不同的技術存儲在文件(或者內存)中。這些技術中的每一種技術都使用不同的存儲機制、索引技巧、鎖定水平並且最終提供廣泛的不同的功能和能力。通過選擇不同的技術,

MySQL InnoDBMyISAM存儲引擎差異

vco 重建 lec insert 需要 系統文件 name 單個 master 前言:   之前簡單介紹過 MySQL 常用的存儲引擎,今天對兩個主流的存儲簡單分析下差異,書上沒有參考的筆試題解答註解; 差異:   MyISAM 只支持表鎖,不支持事務,表損壞

Mysql 存儲引擎中InnoDBMyisam的主要區別

sql mysq where條件 擴展 擴展名 sel 系統 sele sans innodb 支持事務功能,myisam 不支持。 Myisam 的執行速度更快,性能更好。 2、select ,update ,insert ,delete 操作 MyISAM:如果執行

InnoDBMyisam的區別

選擇 映射 myisam 出現 壓縮 select 並發控制 spa 支持 如何選擇存儲引擎: 如果不在乎可擴展能力和並發能力,也不在乎崩潰後數據的所示問題,卻對innoDB的空間占用過多比較敏感,這種場合應該使用MyISAM。否則應該使用InnoDB。如果需要使用在線熱備

InnoDBMyISAM索引結構

image eight width nod 分享 tle isam mage col 事實證明,一知半解在面試的時候是回答不清楚的InnoDB與MyISAM索引結構

INNODBMyISAM兩種表存儲引擎區別

耗時 關系數據庫 data 條件 表空間 height size org lob mysql數據庫分類為INNODB為MyISAM兩種表存儲引擎了,兩種各有優化在不同類型網站可能選擇不同,下面小編為各位介紹mysql更改表引擎INNODB為MyISAM技巧。常見的mysql

(轉)InnoDBMyISAM引擎區別

open 開發 定期 cpu 語句 文件中 有一個 怎麽 isolation MyISAM與InnoDB兩者之間區別與選擇,詳細總結,性能對比 2015年06月25日 21:58:42 閱讀數:1827更多 個人分類: mysql 1、MyISAM

mysql中InnoDBMyISAM的區別

兩者的區別: 1. InnoDB支援事務,MyISAM不支援,對於InnoDB每一條SQL語言都預設封裝成事務,自動提交,這樣會影響速度,所以最好把多條SQL語言放在begin和commit之間,組成一個事務; 2. InnoDB支援外來鍵,而MyISAM不支援。對一個包含外來鍵的InnoDB錶轉為MYI

Innodb MyISAM

一 鎖差異 MyISAM:只支援表級鎖,只支援表級鎖,使用者在操作myisam表時,select,update,delete,insert語句都會給表自動加鎖。 InnodB:支援事務和行級鎖,是innodb的最大特色。行鎖大幅度提高了多使用者併發操作的新能。但是InnoDB的行鎖也不是

MySQL資料庫中 InnoDB MyISAM的區別及其應用場景

InnoDB 與 MyISAM 都是MySQL資料庫的引擎。 1.他們的區別分為五點: (1).事務處理: MyISAM是非事務安全型的,而InnoDB是事務安全型的(支援事務處理等) (2).鎖機制不同: MyISAM是

Mysql 儲存引擎中InnoDBMyisam的主要區別

MVCC ( Multi-Version Concurrency Control )多版本併發控制  InnoDB:通過為每一行記錄新增兩個額外的隱藏的值來實現MVCC,這兩個值一個記錄這行資料何時被建立,另外一個記錄這行資料何時過期(或者被刪除)。但是InnoDB並不儲存這些事件發生時的實際時間,相反它只

InnoDBMyISAM中的count(*)的執行效率比較

今天同學們在群裡討論oracle的count(*)與count(1)的問題,正好提到mysql的情況。我突然想到自己遇到的問題:在myisam引擎執行count(*)速度非常快,而且執行速度與記錄條數無關,而innodb卻不是這樣,記錄越多,速度越慢。     於是做了一個

InnoDBMyISAM資料引擎對比選擇

MySQL優勢之一是外掛式的儲存引擎架構將查詢處理和其它的系統任務以及資料的儲存提取相分離。而MySQL常見的資料庫引擎有兩種:InnoDB和MyISAM,那如何選擇呢? 1.InnoDB和MyISAM對比: 1)MySQL預設採用的是MyISAM。 2)MyISAM

Mysql資料庫InnodbMyISAM的效能對比測試

由於近期有個專案對系統性能要求很高,技術選型上由於種種原因已經確定使用Mysql資料庫,接下來就是要確定到底使用哪種儲存引擎。我們的應用是典型的寫多讀少,寫入內容為也很短,對系統的穩定性要求很高。所以儲存引擎肯定就定在廣泛使用的Innodb和MyISAM之中了。   

MySQL儲存引擎InnoDBMyisam的六大區別

MySQL有多種儲存引擎,每種儲存引擎有各自的優缺點,可以擇優選擇使用: MyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)、EXAMPLE、FEDERATED、ARCHIVE、CSV、BLACKHOLE。 MySQL支援數個

MyISAM INNODB

本文雙引號內容為重要點 ,在markdown中雙引號的內容為紅色 一 MyISAM鎖 表鎖 表鎖:不會出現死鎖,容易發生鎖衝突,併發低 (1) 表鎖的兩種模式: "表共享鎖 (Table R

Innodb中的行

ora 加鎖 表鎖 語句 www targe 都是 速度慢 檢索 在Innodb引擎中既支持行鎖也支持表鎖,那麽什麽時候會鎖住整張表,什麽時候或只鎖住一行呢? InnoDB行鎖是通過給索引上的索引項加鎖來實現的,這一點MySQL與Oracle不同,後者是通過在數據塊中對相應

MySQL/InnoDB中的、悲觀、共享、排它、行、表、死MySQL讀寫分離

MySQL/InnoDB的加鎖,一直是一個面試中常問的話題。例如,資料庫如果有高併發請求,如何保證資料完整性?產生死鎖問題如何排查並解決?我在工作過程中,也會經常用到,樂觀鎖,排它鎖,等。於是今天就對這幾個概念進行學習,屢屢思路,記錄一下。 注:MySQL是一個支援

mysql 實驗論證 innodb表級行級

innodb 的行鎖是在有索引的情況下,沒有索引的表是鎖定全表的. 表鎖演示(無索引) 操作1 操作2 處於等待狀