成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

InnoDB,5項最佳實踐,知其所以然?

開發(fā) 開發(fā)工具
今天,開始寫數(shù)據(jù)庫。第一篇,說說MySQL兩個最常用的存儲引擎,MyISAM和InnoDB。照自己的理解,把一些知識點總結(jié)出來,不只說知識點,多講“為什么”。

今天,開始寫數(shù)據(jù)庫。***篇,說說MySQL兩個最常用的存儲引擎,MyISAM和InnoDB。照自己的理解,把一些知識點總結(jié)出來,不只說知識點,多講“為什么”。

[[241510]]

一、關(guān)于count(*)

知識點:MyISAM會直接存儲總行數(shù),InnoDB則不會,需要按行掃描。

潛臺詞是,對于select count(*) from t; 如果數(shù)據(jù)量大,MyISAM會瞬間返回,而InnoDB則會一行行掃描。

  • 實踐:數(shù)據(jù)量大的表,InnoDB不要輕易select count(*),性能消耗極大。
  • 常見坑:只有查詢?nèi)淼目傂袛?shù),MyISAM才會直接返回結(jié)果,當加了where條件后,兩種存儲引擎的處理方式類似。

例如:

  1. t_user(uid, uname, age, sex); 
  • uid PK
  • age index
  1. select count(*) where age<18 and sex='F' 

查詢未成年少女個數(shù),兩種存儲引擎的處理方式類似,都需要進行索引掃描。

啟示:不管哪種存儲引擎,都要建立好索引。

二、關(guān)于全文索引

  • 知識點:MyISAM支持全文索引,InnoDB5.6之前不支持全文索引。
  • 實踐:不管哪種存儲引擎,在數(shù)據(jù)量大并發(fā)量大的情況下,都不應該使用數(shù)據(jù)庫自帶的全文索引,會導致小量請求占用大量數(shù)據(jù)庫資源,而要使用《索引外置》的架構(gòu)設計方法。
  • 啟示:大數(shù)據(jù)量+高并發(fā)量的業(yè)務場景,全文索引,MyISAM也不是***之選。

三、關(guān)于事務

  • 知識點:MyISAM不支持事務,InnoDB支持事務。
  • 實踐:事務是選擇InnoDB非常誘人的原因之一,它提供了commit,rollback,崩潰修復等能力。在系統(tǒng)異常崩潰時,MyISAM有一定幾率造成文件損壞,這是非常煩的。但是,事務也非常耗性能,會影響吞吐量,建議只對一致性要求較高的業(yè)務使用復雜事務。
  • 畫外音:Can't open file 'XXX.MYI'. 碰到過么?
  • 小技巧:MyISAM可以通過lock table表鎖,來實現(xiàn)類似于事務的東西,但對數(shù)據(jù)庫性能影響較大,強烈不推薦使用。

四、關(guān)于外鍵

  • 知識點:MyISAM不支持外鍵,InnoDB支持外鍵。
  • 實踐:不管哪種存儲引擎,在數(shù)據(jù)量大并發(fā)量大的情況下,都不應該使用外鍵,而建議由應用程序保證完整性。

五、關(guān)于行鎖與表鎖

知識點:MyISAM只支持表鎖,InnoDB可以支持行鎖。

分析:

  • MyISAM:執(zhí)行讀寫SQL語句時,會對表加鎖,所以數(shù)據(jù)量大,并發(fā)量高時,性能會急劇下降。
  • InnoDB:細粒度行鎖,在數(shù)據(jù)量大,并發(fā)量高時,性能比較優(yōu)異。

實踐:網(wǎng)上常常說,select+insert的業(yè)務用MyISAM,因為MyISAM在文件尾部順序增加記錄速度極快。樓主的建議是,絕大部分業(yè)務是混合讀寫,只要數(shù)據(jù)量和并發(fā)量較大,一律使用InnoDB。

常見坑:InnoDB的行鎖是實現(xiàn)在索引上的,而不是鎖在物理行記錄上。潛臺詞是,如果訪問沒有***索引,也無法使用行鎖,將要退化為表鎖。

畫外音:Oracle的行鎖實現(xiàn)機制不同。

例如:

  1. t_user(uid, uname, age, sex) innodb 
  • uid PK
  • 無其他索引
  1. update t_user set age=10 where uid=1 

***索引,行鎖。

  1. update t_user set age=10 where uid != 1 

未***索引,表鎖。

  1. update t_user set age=10 where name='shenjian 

無索引,表鎖。

啟示:InnoDB務必建好索引,否則鎖粒度較大,會影響并發(fā)。

總結(jié)

在大數(shù)據(jù)量,高并發(fā)量的互聯(lián)網(wǎng)業(yè)務場景下,對于MyISAM和InnoDB

  • 有where條件,count(*)兩個存儲引擎性能差不多
  • 不要使用全文索引,應當使用《索引外置》的設計方案
  • 事務影響性能,強一致性要求才使用事務
  • 不用外鍵,由應用程序來保證完整性
  • 不***索引,InnoDB也不能用行鎖

結(jié)論

在大數(shù)據(jù)量,高并發(fā)量的互聯(lián)網(wǎng)業(yè)務場景下,請使用InnoDB:

  • 行鎖,對提高并發(fā)幫助很大
  • 事務,對數(shù)據(jù)一致性幫助很大

這兩個點,是InnoDB最吸引人的地方。

幾個小的知識點,希望大家有收獲。有說的不對的,歡迎大家指正,共同討論。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件,轉(zhuǎn)載請聯(lián)系原作者】

戳這里,看該作者更多好文

責任編輯:趙寧寧 來源: 51CTO專欄
相關(guān)推薦

2022-05-22 10:02:32

CREATESQL 查詢SQL DDL

2022-07-05 09:03:05

Flink SQLTopN

2022-06-10 09:01:04

OverFlinkSQL

2022-06-06 09:27:23

FlinkSQLGroup

2022-05-18 09:02:28

Flink SQLSQL字符串

2020-10-27 12:00:59

SQLite數(shù)據(jù)庫軟件架構(gòu)

2022-06-29 09:01:38

FlinkSQL時間屬性

2022-05-15 09:57:59

Flink SQL時間語義

2022-05-27 09:02:58

SQLHive語義

2021-11-28 11:36:08

SQL Flink Join

2022-08-10 10:05:29

FlinkSQL

2021-11-27 09:03:26

flink join數(shù)倉

2022-05-12 09:02:47

Flink SQL數(shù)據(jù)類型

2021-12-17 07:54:16

Flink SQLTable DataStream

2022-06-18 09:26:00

Flink SQLJoin 操作

2021-12-09 06:59:24

FlinkSQL 開發(fā)

2021-09-12 07:01:07

Flink SQL ETL datastream

2022-05-09 09:03:04

SQL數(shù)據(jù)流數(shù)據(jù)

2021-11-24 08:17:21

Flink SQLCumulate WiSQL

2022-07-12 09:02:18

Flink SQL去重
點贊
收藏

51CTO技術(shù)棧公眾號

主站蜘蛛池模板: 男女羞羞免费视频 | 一区二区福利视频 | 亚洲欧洲日韩 | www.四虎.com| 一区二区三区在线 | 欧 | 黄色一级视频 | 中文字幕不卡在线观看 | 精品久久久久久 | 亚洲播放 | 91亚洲国产成人久久精品网站 | 日韩国产欧美一区 | 精品99在线 | 欧美日日 | 中文字幕一区二区在线观看 | 狠狠操电影 | 人人干人人干人人干 | 亚洲美女一区 | 国产亚洲黄色片 | 久久精品91久久久久久再现 | 亚洲成人99 | 久久久久国产精品一区二区 | 亚洲成人网在线观看 | 天天在线操 | 在线观看黄视频 | 中国一级特黄视频 | 成人av免费看 | 国产不卡一区 | 精品在线一区 | 看av网| 免费色网址| 久久久人成影片免费观看 | 99国内精品久久久久久久 | 欧美男人亚洲天堂 | 日韩中文字幕在线播放 | 99re热这里只有精品视频 | 国产精品久久久久久久三级 | 免费黄色的网站 | 亚洲成人免费观看 | 男女羞羞免费网站 | 欧美午夜一区 | 中文字幕国产精品 |