您現在的位置: 365建站網 > 365學習 > mysql存儲引擎 MyISAM 和 InnoDB 的區別及用法

mysql存儲引擎 MyISAM 和 InnoDB 的區別及用法

文章來源:365jz.com     點擊數:225    更新時間:2021-04-24 23:18   參與評論

InnoDB和MyISAM是很多人在使用MySQL時最常用的兩個表類型,這兩個表類型各有優劣,5.7之后就不一樣了

1、事務和外鍵

InnoDB具有事務,支持4個事務隔離級別,回滾,崩潰修復能力和多版本并發的事務安全,包括ACID。如果應用中需要執行大量的INSERT或UPDATE操作,則應該使用InnoDB,這樣可以提高多用戶并發操作的性能

MyISAM管理非事務表。它提供高速存儲和檢索,以及全文搜索能力。如果應用中需要執行大量的SELECT查詢,那么MyISAM是更好的選擇

2、全文索引

Innodb不支持全文索引,如果一定要用的話,最好使用sphinx等搜索引擎。myisam對中文支持的不是很好

不過新版本的Innodb已經支持了

3、鎖

mysql支持三種鎖定級別,行級、頁級、表級;

MyISAM支持表級鎖定,提供與 Oracle 類型一致的不加鎖讀取(non-locking read in SELECTs)

InnoDB支持行級鎖,InnoDB表的行鎖也不是絕對的,如果在執行一個SQL語句時MySQL不能確定要掃描的范圍,InnoDB表同樣會鎖全表,注意間隙鎖的影響

例如update table set num=1 where name like “%aaa%”

4、存儲

MyISAM在磁盤上存儲成三個文件。第一個文件的名字以表的名字開始,擴展名指出文件類型, .frm文件存儲表定義,數據文件的擴展名為.MYD,  索引文件的擴展名是.MYI

InnoDB,基于磁盤的資源是InnoDB表空間數據文件和它的日志文件,InnoDB 表的大小只受限于操作系統文件的大小

注意:MyISAM表是保存成文件的形式,在跨平臺的數據轉移中使用MyISAM存儲會省去不少的麻煩

5、索引

InnoDB(索引組織表)使用的聚簇索引、索引就是數據,順序存儲,因此能緩存索引,也能緩存數據

MyISAM(堆組織表)使用的是非聚簇索引、索引和文件分開,隨機存儲,只能緩存索引

6、并發

MyISAM讀寫互相阻塞:不僅會在寫入的時候阻塞讀取,MyISAM還會在讀取的時候阻塞寫入,但讀本身并不會阻塞另外的讀

InnoDB 讀寫阻塞與事務隔離級別相關

7、場景選擇

MyISAM

  • 不需要事務支持(不支持)

  • 并發相對較低(鎖定機制問題)

  • 數據修改相對較少(阻塞問題),以讀為主

  • 數據一致性要求不是非常高

  1. 盡量索引(緩存機制)

  2. 調整讀寫優先級,根據實際需求確保重要操作更優先

  3. 啟用延遲插入改善大批量寫入性能

  4. 盡量順序操作讓insert數據都寫入到尾部,減少阻塞

  5. 分解大的操作,降低單個操作的阻塞時間

  6. 降低并發數,某些高并發場景通過應用來進行排隊機制

  7. 對于相對靜態的數據,充分利用Query Cache可以極大的提高訪問效率

  8. MyISAM的Count只有在全表掃描的時候特別高效,帶有其他條件的count都需要進行實際的數據訪問

InnoDB 

  • 需要事務支持(具有較好的事務特性)

  • 行級鎖定對高并發有很好的適應能力,但需要確保查詢是通過索引完成

  • 數據更新較為頻繁的場景

  • 數據一致性要求較高

  • 硬件設備內存較大,可以利用InnoDB較好的緩存能力來提高內存利用率,盡可能減少磁盤 IO

  1. 主鍵盡可能小,避免給Secondary index帶來過大的空間負擔

  2. 避免全表掃描,因為會使用表鎖

  3. 盡可能緩存所有的索引和數據,提高響應速度

  4. 在大批量小插入的時候,盡量自己控制事務而不要使用autocommit自動提交

  5. 合理設置innodb_flush_log_at_trx_commit參數值,不要過度追求安全性

  6. 避免主鍵更新,因為這會帶來大量的數據移動

8、其它細節

1)InnoDB 中不保存表的具體行數,注意的是,當count(*)語句包含 where條件時,兩種表的操作是一樣的

2)對于AUTO_INCREMENT類型的字段,InnoDB中必須包含只有該字段的索引,但是在MyISAM表中,可以和其他字段一起建立聯合索引, 如果你為一個表指定AUTO_INCREMENT列,在數據詞典里的InnoDB表句柄包含一個名為自動增長計數器的計數器,它被用在為該列賦新值。自動增長計數器僅被存儲在主內存中,而不是存在磁盤

3)DELETE FROM table時,InnoDB不會重新建立表,而是一行一行的刪除

4)LOAD TABLE FROM MASTER操作對InnoDB是不起作用的,解決方法是首先把InnoDB表改成MyISAM表,導入數據后再改成InnoDB表,但是對于使用的額外的InnoDB特性(例如外鍵)的表不適用

5)如果執行大量的SELECT,MyISAM是更好的選擇,如果你的數據執行大量的INSERT或UPDATE,出于性能方面的考慮,應該使用InnoDB表

7、為什么MyISAM會比Innodb 的查詢速度快

InnoDB 在做SELECT的時候,要維護的東西比MYISAM引擎多很多;

1)InnoDB 要緩存數據和索引,MyISAM只緩存索引塊,這中間還有換進換出的減少

2)innodb尋址要映射到塊,再到行,MyISAM記錄的直接是文件的OFFSET,定位比INNODB要快

3)InnoDB 還需要維護MVCC一致;雖然你的場景沒有,但他還是需要去檢查和維護

MVCC ( Multi-Version Concurrency Control )多版本并發控制

InnoDB :通過為每一行記錄添加兩個額外的隱藏的值來實現MVCC,這兩個值一個記錄這行數據何時被創建,另外一個記錄這行數據何時過期(或者被刪除)。但是InnoDB并不存儲這些事件發生時的實際時間,相反它只存儲這些事件發生時的系統版本號。這是一個隨著事務的創建而不斷增長的數字。每個事務在事務開始時會記錄它自己的系統版本號。每個查詢必須去檢查每行數據的版本號與事務的版本號是否相同。讓我們來看看當隔離級別是REPEATABLE READ時這種策略是如何應用到特定的操作的

SELECT InnoDB必須每行數據來保證它符合兩個條件

1、InnoDB必須找到一個行的版本,它至少要和事務的版本一樣老(也即它的版本號不大于事務的版本號)。這保證了不管是事務開始之前,或者事務創建時,或者修改了這行數據的時候,這行數據是存在的。

2、這行數據的刪除版本必須是未定義的或者比事務版本要大。這可以保證在事務開始之前這行數據沒有被刪除。

8、mysql性能討論

MyISAM最為人垢病的缺點就是缺乏事務的支持

InnoDB 的磁盤性能很令人擔心

MySQL 缺乏良好的 tablespace 



兩種類型最主要的差別就是Innodb 支持事務處理與外鍵和行級鎖.而MyISAM不支持.所以MyISAM往往就容易被人認為只適合在小項目中使用。

我作為使用MySQL的用戶角度出發,Innodb和MyISAM都是比較喜歡的,但是從我目前運維的數據庫平臺要達到需求:99.9%的穩定性,方便的擴展性和高可用性來說的話,MyISAM絕對是我的首選。

原因如下:

1、首先我目前平臺上承載的大部分項目是讀多寫少的項目,而MyISAM的讀性能是比Innodb強不少的。

2、MyISAM的索引和數據是分開的,并且索引是有壓縮的,內存使用率就對應提高了不少。能加載更多索引,而Innodb是索引和數據是緊密捆綁的,沒有使用壓縮從而會造成Innodb比MyISAM體積龐大不小。

3、從平臺角度來說,經常隔1,2個月就會發生應用開發人員不小心update一個表where寫的范圍不對,導致這個表沒法正常用了,這個時候MyISAM的優越性就體現出來了,隨便從當天拷貝的壓縮包取出對應表的文件,隨便放到一個數據庫目錄下,然后dump成sql再導回到主庫,并把對應的binlog補上。如果是Innodb,恐怕不可能有這么快速度,別和我說讓Innodb定期用導出xxx.sql機制備份,因為我平臺上最小的一個數據庫實例的數據量基本都是幾十G大小。

4、從我接觸的應用邏輯來說,select count(*) 和order by 是最頻繁的,大概能占了整個sql總語句的60%以上的操作,而這種操作Innodb其實也是會鎖表的,很多人以為Innodb是行級鎖,那個只是where對它主鍵是有效,非主鍵的都會鎖全表的。

5、還有就是經常有很多應用部門需要我給他們定期某些表的數據,MyISAM的話很方便,只要發給他們對應那表的frm.MYD,MYI的文件,讓他們自己在對應版本的數據庫啟動就行,而Innodb就需要導出xxx.sql了,因為光給別人文件,受字典數據文件的影響,對方是無法使用的。

6、如果和MyISAM比insert寫操作的話,Innodb還達不到MyISAM的寫性能,如果是針對基于索引的update操作,雖然MyISAM可能會遜色Innodb,但是那么高并發的寫,從庫能否追的上也是一個問題,還不如通過多實例分庫分表架構來解決。

7、如果是用MyISAM的話,merge引擎可以大大加快應用部門的開發速度,他們只要對這個merge表做一些select count(*)操作,非常適合大項目總量約幾億的rows某一類型(如日志,調查統計)的業務表。

當然Innodb也不是絕對不用,用事務的項目如模擬炒股項目,我就是用Innodb的,活躍用戶20多萬時候,也是很輕松應付了,因此我個人也是很喜歡Innodb的,只是如果從數據庫平臺應用出發,我還是會首選MyISAM。

另外,可能有人會說你MyISAM無法抗太多寫操作,但是我可以通過架構來彌補,說個我現有用的數據庫平臺容量:主從數據總量在幾百T以上,每天十多億 pv的動態頁面,還有幾個大項目是通過數據接口方式調用未算進pv總數,(其中包括一個大項目因為初期memcached沒部署,導致單臺數據庫每天處理 9千萬的查詢)。而我的整體數據庫服務器平均負載都在0.5-1左右。

總結

在數據庫開發中,了解不同存儲引擎的索引實現方式對于正確使用和優化索引都非常有幫助。例如,知道了InnoDB的索引實現后,就很容易明白為什么不建議使用過長的字段作為主鍵,因為所有輔助索引都引用主索引,過長的主索引會令輔助索引變得過大。再例如,用非單調的字段作為主鍵在InnoDB中不是個好做法,因為InnoDB數據文件本身是一顆B+Tree,非單調的主鍵會造成在插入新記錄時數據文件為了維持B+Tree的特性而頻繁的分裂調整,十分低效,而使用自增字段作為主鍵則是一個很好的選擇。


區別:

1. InnoDB 支持事務,MyISAM 不支持事務。這是 MySQL 將默認存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一;

2. InnoDB 支持外鍵,而 MyISAM 不支持。對一個包含外鍵的 InnoDB 表轉為 MYISAM 會失??;

3. InnoDB 是聚集索引,MyISAM 是非聚集索引。聚簇索引的文件存放在主鍵索引的葉子節點上,因此 InnoDB 必須要有主鍵,通過主鍵索引效率很高。但是輔助索引需要兩次查詢,先查詢到主鍵,然后再通過主鍵查詢到數據。因此,主鍵不應該過大,因為主鍵太大,其他索引也都會很大。而 MyISAM 是非聚集索引,數據文件是分離的,索引保存的是數據文件的指針。主鍵索引和輔助索引是獨立的。

4. InnoDB 不保存表的具體行數,執行 select count(*) from table 時需要全表掃描。而MyISAM 用一個變量保存了整個表的行數,執行上述語句時只需要讀出該變量即可,速度很快;

5. InnoDB 最小的鎖粒度是行鎖,MyISAM 最小的鎖粒度是表鎖。一個更新語句會鎖住整張表,導致其他查詢和更新都會被阻塞,因此并發訪問受限。這也是 MySQL 將默認存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一;

如何選擇:

1. 是否要支持事務,如果要請選擇 InnoDB,如果不需要可以考慮 MyISAM;

2. 如果表中絕大多數都只是讀查詢,可以考慮 MyISAM,如果既有讀寫也挺頻繁,請使用InnoDB。

3. 系統奔潰后,MyISAM恢復起來更困難,能否接受,不能接受就選 InnoDB;

4. MySQL5.5版本開始Innodb已經成為Mysql的默認引擎(之前是MyISAM),說明其優勢是有目共睹的。如果你不知道用什么存儲引擎,那就用InnoDB,至少不會差。


比較常用的是 MyISAM 和 InnoBD


  MyISAM

  
  InnoDB

  
  構成上的區別:

  
  每個MyISAM在磁盤上存儲成三個文件。第一個文件的名字以表的名字開始,擴展名指出文件類型。

  .frm文件存儲表定義。

  數據文件的擴展名為.MYD (MYData)。

  索引文件的擴展名是.MYI (MYIndex)。

  
  基于磁盤的資源是InnoDB表空間數據文件和它的日志文件,InnoDB 表的大小只受限于操作系統文件的大小,一般為 2GB
  
  事務處理上方面:

  
  MyISAM類型的表強調的是性能,其執行數度比InnoDB類型更快,但是不提供事務支持

  
  InnoDB提供事務支持事務,外部鍵(foreign key)等高級數據庫功能

  
  SELECT   UPDATE,INSERT,Delete操作
  
  如果執行大量的SELECT,MyISAM是更好的選擇

  
  1.如果你的數據執行大量的INSERTUPDATE,出于性能方面的考慮,應該使用InnoDB表

  2.DELETE   FROM table時,InnoDB不會重新建立表,而是一行一行的刪除。

  3.LOAD   TABLE FROM MASTER操作對InnoDB是不起作用的,解決方法是首先把InnoDB表改成MyISAM表,導入數據后再改成InnoDB表,但是對于使用的額外的InnoDB特性(例如外鍵)的表不適用

  
  AUTO_INCREMENT的操作

  
  
  每表一個AUTO_INCREMEN列的內部處理。

  MyISAMINSERTUPDATE操作自動更新這一列。這使得AUTO_INCREMENT列更快(至少10%)。在序列頂的值被刪除之后就不能再利用。(當AUTO_INCREMENT列被定義為多列索引的最后一列,可以出現重使用從序列頂部刪除的值的情況)。

  AUTO_INCREMENT值可用ALTER TABLE或myisamch來重置

  對于AUTO_INCREMENT類型的字段,InnoDB中必須包含只有該字段的索引,但是在MyISAM表中,可以和其他字段一起建立聯合索引

  更好和更快的auto_increment處理

  
  如果你為一個表指定AUTO_INCREMENT列,在數據詞典里的InnoDB表句柄包含一個名為自動增長計數器的計數器,它被用在為該列賦新值。

  自動增長計數器僅被存儲在主內存中,而不是存在磁盤上

  關于該計算器的算法實現,請參考

  AUTO_INCREMENT列在InnoDB里如何工作

  
  表的具體行數
  
  select count(*) from table,MyISAM只要簡單的讀出保存好的行數,注意的是,當count(*)語句包含   where條件時,兩種表的操作是一樣的

  
  InnoDB 中不保存表的具體行數,也就是說,執行select count(*) from table時,InnoDB要掃描一遍整個表來計算有多少行

  
  
  
  表鎖

  
  提供行鎖(locking on row level),提供與 Oracle 類型一致的不加鎖讀取(non-locking read in
   SELECTs),另外,InnoDB表的行鎖也不是絕對的,如果在執行一個SQL語句時MySQL不能確定要掃描的范圍,InnoDB表同樣會鎖全表, 例如update table set num=1 where name like "%aaa%"

MySQL 存儲引擎 MyISAM 與 InnoDB 如何選擇?

雖然 MySQL 里的存儲引擎不只是 MyISAM 與 InnoDB 這兩個,但常用的就是它倆了??赡苡姓鹃L并未注意過 MySQL 的存儲引擎,其實存儲引擎也是數據庫設計里的一大重要點,那么博客系統應該使用哪種存儲引擎呢?

下面我們分別來看兩種存儲引擎的區別。

  • 一、InnoDB支持事務,MyISAM不支持,這一點是非常之重要。事務是一種高級的處理方式,如在一些列增刪改中只要哪個出錯還可以回滾還原,而MyISAM就不可以了。

  • 二、MyISAM適合查詢以及插入為主的應用,InnoDB適合頻繁修改以及涉及到安全性較高的應用

  • 三、InnoDB支持外鍵,MyISAM不支持

  • 四、MyISAM是默認引擎,InnoDB需要指定

  • 五、InnoDB不支持FULLTEXT類型的索引

  • 六、InnoDB中不保存表的行數,如select count(*) from table時,InnoDB需要掃描一遍整個表來計算有多少行,但是MyISAM只要簡單的讀出保存好的行數即可。注意的是,當count(*)語句包含where條件時MyISAM也需要掃描整個表

  • 七、對于自增長的字段,InnoDB中必須包含只有該字段的索引,但是在MyISAM表中可以和其他字段一起建立聯合索引

  • 八、清空整個表時,InnoDB是一行一行的刪除,效率非常慢。MyISAM則會重建表

  • 九、InnoDB支持行鎖(某些情況下還是鎖整表,如 update table set a=1 where user like '%lee%'

通過以上九點區別,結合個人博客的特點,推薦個人博客系統使用MyISAM,因為在博客里主要操作是讀取和寫入,很少有鏈式操作。所以選擇MyISAM引擎使你博客打開也頁面的效率要高于InnoDB引擎的博客,當然只是個人的建議,大多數博客還是根據實際情況下謹慎選擇。

一些關于MyISAM與InnoDB選擇使用:

MYISAM和INNODB是Mysql數據庫提供的兩種存儲引擎。兩者的優劣可謂是各有千秋。INNODB會支持一些關系數據庫的高級功能,如事務功能和行級鎖,MYISAM不支持。MYISAM的性能更優,占用的存儲空間少。所以,選擇何種存儲引擎,視具體應用而定。

如果你的應用程序一定要使用事務,毫無疑問你要選擇INNODB引擎。但要注意,INNODB的行級鎖是有條件的。在where條件沒有使用主鍵時,照樣會鎖全表。比如DELETE FROM mytable這樣的刪除語句。

如果你的應用程序對查詢性能要求較高,就要使用MYISAM了。MYISAM索引和數據是分開的,而且其索引是壓縮的,可以更好地利用內存。所以它的查詢性能明顯優于INNODB。壓縮后的索引也能節約一些磁盤空間。MYISAM擁有全文索引的功能,這可以極大地優化LIKE查詢的效率。

有人說MYISAM只能用于小型應用,其實這只是一種偏見。如果數據量比較大,這是需要通過升級架構來解決,比如分表分庫,而不是單純地依賴存儲引擎。

其他一些說法:

現在一般都是選用innodb了,主要是myisam的全表鎖,讀寫串行問題,并發效率鎖表,效率低myisam對于讀寫密集型應用一般是不會去選用的。

關于Mysql數據庫默認的存儲引擎:

MyISAM和InnoDB是MySQL的兩種存儲引擎。如果是默認安裝,那就應該是InnoDB,你可以在my.ini文件中找到default-storage-engine=INNODB;當然你可以在建表時指定相應的存儲引擎。通過show create table xx 可以看見相應信息。

Mysql中InnoDB和MyISAM的比較

MyISAM:

每個MyISAM在磁盤上存儲成三個文件。第一個文件的名字以表的名字開始,擴展名指出文件類型。.frm文件存儲表定義。數據文件的擴展名為.MYD (MYData)。

MyISAM表格可以被壓縮,而且它們支持全文搜索。不支持事務,而且也不支持外鍵。如果事物回滾將造成不完全回滾,不具有原子性。在進行updata時進行表鎖,并發量相對較小。如果執行大量的SELECT,MyISAM是更好的選擇。

MyISAM的索引和數據是分開的,并且索引是有壓縮的,內存使用率就對應提高了不少。能加載更多索引,而Innodb是索引和數據是緊密捆綁的,沒有使用壓縮從而會造成Innodb比MyISAM體積龐大不小

MyISAM緩存在內存的是索引,不是數據。而InnoDB緩存在內存的是數據,相對來說,服務器內存越大,InnoDB發揮的優勢越大。

優點:查詢數據相對較快,適合大量的select,可以全文索引。

缺點:不支持事務,不支持外鍵,并發量較小,不適合大量update

InnoDB:

這種類型是事務安全的。.它與BDB類型具有相同的特性,它們還支持外鍵。InnoDB表格速度很快。具有比BDB還豐富的特性,因此如果需要一個事務安全的存儲引擎,建議使用它。在update時表進行行鎖,并發量相對較大。如果你的數據執行大量的INSERT或UPDATE,出于性能方面的考慮,應該使用InnoDB表。

優點:支持事務,支持外鍵,并發量較大,適合大量update

缺點:查詢數據相對較快,不適合大量的select

對于支持事物的InnoDB類型的表,影響速度的主要原因是AUTOCOMMIT默認設置是打開的,而且程序沒有顯式調用BEGIN 開始事務,導致每插入一條都自動Commit,嚴重影響了速度??梢栽趫绦衧ql前調用begin,多條sql形成一個事物(即使autocommit打開也可以),將大大提高性能。

基本的差別為:MyISAM類型不支持事務處理等高級處理,而InnoDB類型支持。

MyISAM類型的表強調的是性能,其執行數度比InnoDB類型更快,但是不提供事務支持,而InnoDB提供事務支持已經外部鍵等高級數據庫功能。

其他比較:

MyIASM是IASM表的新版本,有如下擴展:

  • 二進制層次的可移植性。

  • NULL列索引。

  • 對變長行比ISAM表有更少的碎片。

  • 支持大文件。

  • 更好的索引壓縮。

  • 更好的鍵嗎統計分布。

  • 更好和更快的auto_increment處理。

以下是一些細節和具體實現的差別:

  • 1.InnoDB不支持FULLTEXT類型的索引。

  • 2.InnoDB 中不保存表的具體行數,也就是說,執行select count(*) from table時,InnoDB要掃描一遍整個表來計算有多少行,但是MyISAM只要簡單的讀出保存好的行數 即可。注意的是,當count(*)語句包含 where條件時,兩種表的操作是一樣的。

  • 3.對于AUTO_INCREMENT類型的字段,InnoDB中必須包含只有該字段的索引,但是在MyISAM表中,可以和其他字段一起建立聯合索引。

  • 4.DELETE FROM table時,InnoDB不會重新建立表,而是一行一行的刪除。

  • 5.LOAD TABLE FROM MASTER操作對InnoDB是不起作用的,解決方法是首先把InnoDB表改成MyISAM表,導入數據后再改成InnoDB表,但是對于使用的額外的 InnoDB特性(例如外鍵)的表不適用。

另外,InnoDB表的行鎖也不是絕對的,如果在執行一個SQL語句時MySQL不能確定要掃描的范圍,InnoDB表同樣會鎖全表,例如update table set num=1 where name like "%aaa%"

任何一種表都不是萬能的,只用恰當的針對業務類型來選擇合適的表類型,才能最大的發揮MySQL的性能優勢。

innodb和myisam更新比較:

innodb的數據組織就是按照主鍵建成的一個B+樹,如果沒有顯示的定義主鍵,那么innodb會選區一個not null unique key,作為主鍵,如果還是沒有,那么innodb會創建一個 6字節的主鍵,主鍵索引到頁不是具體的行位置

不是遞增的主鍵會使得插入的速度很慢,例如使用手機號或身份證號做為主鍵,所以善用AUTO_INCREMENT

表大不可怕,可怕的是count或者高偏移limit,可以將大的limit big換成 limit max_id, xxxxx

Limit 0 1000 | limit 1001 1000 | limit 2001 1000Limit 0 1000 | where id>max_id1 limit 1000 | where id>max_id2 limit 1000

對于InnoDB來說,按照某列分表,想在單臺服務器上提高性能是沒有意義的

插入的速度和查詢的速度有時候是不可調和的矛盾

說InnoDB不適合做count是不對的,MyISAM也是一樣的慢,只不過MyISAM將正表的行數緩存起來,所以count整表很快,如果有查詢條件,并且不是主鍵查詢,那就沒有什么區別,主鍵count慢的原因是innodb是按照主鍵組織的,按照主鍵count的時候,會加載數據

InnoDB的頁式存儲會使得InnoDB更容易做整表緩存和熱備份

如果表索引很多,那么InnoDB的更新速度要大于MyISAM,因為InnoDB的輔助索引關聯的是表的主鍵,是一個邏輯的值,而MyISAM的所有索引關聯的是數據的物理位置,更新時有可能數據的物理位置發生變化,如果發生變化,那么所有的索引都要做更新

InnoDB 中不保存表的具體行數,也就是說,執行select count(*) from table時,InnoDB要掃描一遍整個表來計算有多少行,但是MyISAM只要簡單的讀出保存好的行數即可。注意的是,當count(*)語句包含 where條件時,兩種表的操作是一樣的。


如對本文有疑問,請提交到交流論壇,廣大熱心網友會為你解答??! 點擊進入論壇


發表評論 (225人查看,0條評論)
請自覺遵守互聯網相關的政策法規,嚴禁發布色情、暴力、反動的言論。
用戶名: 驗證碼: 點擊我更換圖片
最新評論
------分隔線----------------------------
自拍偷拍福力视频,偷拍国际精品,麻豆一区福利电影,国产网红视频午夜福利,se视频大全,久久国产AV影院 国产多p交换视频无码| 性欧美暴力猛交69hd| 国产精品欧美亚洲韩国日本久久| 风韵多水的老熟妇| 深夜福利视频第四集| 特级婬片日本高清完整视频| 黑人无套内谢中国少妇| 少妇被粗大的猛进出69影院| 欧美人与禽交zozo| 久久99精品久久久久久| 香蕉啪视频在线观看视频久| 夜夜噜2017最新在线| 欧美精品黑人粗大破除| 边摸边吃奶边做激情叫床视频| 人人妻人人澡人人爽秒播| 香港三级强奷在线观看| 青娱乐视觉盛宴精品| 宝贝慢慢来| 国产亚洲人成网站在线观看| 被强行灌满精子的少妇| 女女同性黄网| 天干天干啦夜天天喷水| 香蕉97超级碰碰碰免费公开18| av大片不卡永久免费网址| 免费人成视频xvideos入口| 国内久久这里只有精品| 你的好大啊我还想要| 国内自拍久久久久| 中文字幕韩国三级理论| 厕所RXXX| 正在播放国产对白孕妇作爱| http://www.blackhistoryportraits.com