當為每個表設計具有適當主鍵列的資料庫時，涉及這些列的操作會自動進行優化。在WHERE子句，ORDER BY子句，GROUP BY子句和聯接操作中引用主鍵列非常快速。
插入，更新和刪除通過稱為更改緩衝的自動機制進行了優化。InnoDB不僅允許對同一表的併發讀寫訪問，而且還快取更改的資料以簡化磁碟I / O。
效能優勢不僅限於具有長時間執行的查詢的大型表。當從表中一遍又一遍地訪問相同的行時，自適應雜湊索引將接管這些查詢，使它們的查詢速度更快，就好像它們來自雜湊表一樣。
可以壓縮表和關聯的索引
可以加密資料
可以建立和刪除索引並執行其他DDL操作，而對效能和可用性的影響要小得多
截斷每表文件表空間非常快，可以釋放磁碟空間供作業系統重用，而不是僅重用InnoDB
BLOB使用DYNAMIC行格式，對於長文字欄位，表資料的儲存佈局更為有效

2.2擴充套件知識：BLOB和TEXT型別 ^

ABLOB是一個二進位制大物件，可以容納可變數量的資料。這四個BLOB 型別TINYBLOB，BLOB， MEDIUMBLOB，和LONGBLOB。這些僅在它們可以容納的值的最大長度上有所不同。這四個TEXT型別 TINYTEXT，TEXT， MEDIUMTEXT，和LONGTEXT。這些對應於四種BLOB型別，並且具有相同的最大長度和儲存要求。
BLOB值被視為二進位制字串（位元組字串）。它們具有binary 字符集和排序規則，並且比較和排序基於列值中位元組的數字值。 TEXT值被視為非二進位制字串（字元字串）。它們具有以外的字符集 binary，並且根據字符集的排序規則對值進行排序和比較。

繼續說優勢：

可以通過查詢INFORMATION_SCHEMA表來監視儲存引擎的內部工作情況
可以通過查詢效能架構表來監視儲存引擎的效能詳細資訊
可以將InnoDB表與其他MySQL儲存引擎的表混合使用，即使在同一條語句中也可以。例如，可以使用聯接操作在單個查詢中合併來自InnoDB和 MEMORY表的資料。
InnoDB設計用於處理大資料量時的CPU效率和最佳效能。
InnoDB表可以處理大量資料，即使在檔案大小限制為2GB的作業系統上也一樣。

3.要是想要優化innodb可以看具體的8.0innodb表優化

3.1優化型別有這麼幾項

1優化InnoDB表的儲存佈局
2優化InnoDB事務管理
3優化InnoDB只讀事務
4優化InnoDB重做日誌
5 InnoDB表的批量資料載入
6優化InnoDB查詢
7優化InnoDB DDL操作
8優化InnoDB磁碟I / O
9優化InnoDB配置變數
10為具有多個表的系統優化InnoDB

主要優勢就是上邊這些了，這裡還加了部分的知識擴充套件，便於瞭解，如優化、BLOB、恢復

4.各型別索引及各類功能對應各型別儲存引擎支援表，總覽

4.1可以主看標紅的

特徵、功能、索引	特徵、功能、索引	MyISAM	Memory	InnoDB	Archive	NDB
B-tree indexes	B樹索引	是	是	是	沒有	沒有
Backup/point-in-time recovery (note 1)	備份/時間點恢復（註釋1）	是	是	是	是	是
Cluster database support	叢集資料庫支援	沒有	沒有	沒有	沒有	是
Clustered indexes	聚集索引	沒有	沒有	是	沒有	沒有
Compressed data	壓縮資料	是（註釋2）	沒有	是	是	沒有
Data caches	資料快取	沒有	不適用	是	沒有	是
Encrypted data	加密資料	是（註釋3）	是（註釋3）	是（註釋4）	是（註釋3）	是（註釋3）
Foreign key support	外來鍵支援	沒有	沒有	是	沒有	是（註釋5）
Full-text search indexes	全文搜尋索引	是	沒有	是（註釋6）	沒有	沒有
Geospatial data type support	地理空間資料型別支援	是	沒有	是	是	是
Geospatial indexing support	地理空間索引支援	是	沒有	是（註釋7）	沒有	沒有
Hash indexes	雜湊索引	沒有	是	否（註釋8）	沒有	是
Index caches	索引快取	是	不適用	是	沒有	是
Locking granularity	鎖定粒度	表	表	行	行	行
MVCC	MVCC	沒有	沒有	是	沒有	沒有
Replication support (note 1)	複製支援（註釋1）	是	限量（附註9）	是	是	是
Storage limits	儲存限制	256TB	記憶體	64TB	沒有	384EB
T-tree indexes	T樹索引	沒有	沒有	沒有	沒有	是
Transactions	交易次數	沒有	沒有	是	沒有
Update statistics for data dictionary	更新資料字典的統計資訊	是	是	是	是	是

4.2innodb 儲存引擎和對應的給型別索引支援情況

特徵、功能、索引	特徵、功能、索引	支援情況
B-tree indexes	B樹索引	是
Backup/point-in-time recovery(Implemented in the server, rather than in the storage engine.)	備份/時間點恢復（在伺服器中而不是在儲存引擎中實現。）	是
Cluster database support	叢集資料庫支援	沒有
Clustered indexes	聚集索引	是
Compressed data	壓縮資料	是
Data caches	資料快取	是
Encrypted data	加密資料	是（通過加密功能在伺服器中實現；在MySQL 5.7和更高版本中，支援靜態資料加密。）
Foreign key support	外來鍵支援	是
Full-text search indexes	全文搜尋索引	是（MySQL 5.6及更高版本中提供了對FULLTEXT索引的支援。）
Geospatial data type support	地理空間資料型別支援	是
Geospatial indexing support	地理空間索引支援	是（在5.7和更高版本中提供了對地理空間索引的支援。）
Hash indexes	雜湊索引	否（InnoDB在內部將雜湊索引用於其自適應雜湊索引功能。）
Index caches	索引快取	是
Locking granularity	鎖定粒度	行
MVCC	MVCC	是
Replication support(Implemented in the server, rather than in the storage engine.)	複製支援（在伺服器中而不是在儲存引擎中實現。）	是
Storage limits	儲存限制	64TB
T-tree indexes	T樹索引	沒有
Transactions	交易次數	是
Update statistics for data dictionary	更新資料字典的統計資訊	是

5.索引型別

5.1Full Text

全文索引，一般資料文字多的使用

FULLTEXT索引用於全文搜尋。只有InnoDB和MyISAM儲存引擎支援FULLTEXT索引和僅適用於CHAR，VARCHAR和TEXT列。索引始終在整個列上進行，並且不支援列字首索引。

5.2Unique

這個是唯一索引，全表唯一的一個

5.3Normal

這個是普通索引

6.索引方法

7.mysql8.0 的優化和索引

改善操作效能的最佳方法 SELECT是在查詢中測試的一個或多個列上建立索引。索引條目的作用類似於指向錶行的指標，從而使查詢可以快速確定哪些行與WHERE子句中的條件匹配，並檢索這些行的其他列值。所有MySQL資料型別都可以建立索引。
儘管可能會為查詢中使用的每個可能的列建立索引，但不必要的索引會浪費空間和時間，使MySQL難以確定要使用的索引。索引還會增加插入，更新和刪除的成本，因為必須更新每個索引。您必須找到適當的平衡，才能使用最佳索引集來實現快速查詢。

8.索引使用

大多數MySQL索引（PRIMARY KEY， UNIQUE，INDEX和 FULLTEXT）儲存在 B樹。例外：空間資料型別的索引使用R樹；MEMORY 表還支援雜湊索引; InnoDB對FULLTEXT索引使用倒排列表。

WHERE快速查詢與子句匹配的行

從考慮中消除行。如果可以在多個索引之間進行選擇，MySQL通常會使用找到最少行數的索引

如果表具有多列索引，那麼優化器可以使用索引的任何最左字首來查詢行。舉例來說，如果你有一個三列的索引(col1, col2, col3)，你有索引的搜尋功能(col1)，(col1, col2)以及(col1, col2, col3)。

不是同一款字符集，索引會被排除使用如utf-8 和latin1列進行比較會排除使用索引

9.Btree和hash索引的比較

9.1Btree

A B樹索引可以在使用表示式中使用的對列的比較=，>，>=，<，<=，或BETWEEN運營商。

LIKE如果to的引數LIKE是不以萬用字元開頭的常量字串，則索引也可以用於比較。

9.1.1以下WHERE子句使用索引：

... WHERE index_part1=1 AND index_part2=2 AND other_column=3

  /* index = 1 OR index = 2 */
... WHERE index=1 OR A=10 AND index=2

  /* optimized like "index_part1='hello'" */
... WHERE index_part1='hello' AND index_part3=5

  /* Can use index on index1 but not on index2 or index3 */
... WHERE index1=1 AND index2=2 OR index1=3 AND index3=3;

9.1.2這些WHERE子句不使用索引：

  /* index_part1 is not used */
... WHERE index_part2=1 AND index_part3=2

  /* Index is not used in both parts of the WHERE clause */
... WHERE index=1 OR A=10

  /* No index spans all rows */
... WHERE index_part1=1 OR index_part2=10

有時，即使索引可用，MySQL也不使用索引。發生這種情況的一種情況是，優化器估計使用索引將需要MySQL訪問表中很大比例的行。（在這種情況下，表掃描可能會更快，因為它需要更少的查詢。）但是，如果這樣的查詢LIMIT僅用於檢索某些行，則MySQL仍將使用索引，因為它可以更快地找到索引。幾行返回結果。

9.2雜湊指數特徵

雜湊索引與Btree索引具有一些不同的特徵：

它們僅用於使用=or<=>運算子的相等比較（但非常快）。它們不用於比較運算子，例如<用於查詢值範圍的運算子。依賴於這種單值查詢型別的系統稱為“鍵值儲存”；要將MySQL用於此類應用程式，請儘可能使用雜湊索引。
優化器無法使用雜湊索引來加速ORDER BY操作。（此索引型別不能用於按順序搜尋下一個條目。）
MySQL無法確定兩個值之間大約有多少行（範圍優化器使用它來決定要使用哪個索引）。如果將MyISAM或InnoDB表更改為雜湊索引MEMORY表，這可能會影響某些查詢。
僅整個鍵可用於搜尋行。（對於B樹索引，鍵的任何最左邊的字首都可用於查詢行。）

10.索引方法、索引型別總結策略

10.1索引方法

10.1.1Btree

業務專案，有需要對資料範圍比大小的方式查詢資料，這種型別可以採用Btree 索引方法

btree 可以比較範圍 > < <= >= 這型別比較方便

10.1.2hash

業務專案，如有的金額，單獨金額對應單獨金額查詢，或單獨的，通過元件查詢對應的值，這種可以使用Hash 索引方法

hash 索引將索引內容進行了hash 索引索引值比較比= 或<=> 會很快

10.2索引型別

10.2.1Normal

普通索引，沒啥限制

10.2.2Unique

唯一值得實惠便於使用 key 使用

10.2.3Full Text

全文索引，這玩意文字特別多的時候使用比較好

11.應用分析

所以使用的時候更具10.索引方法、索引型別總結策略，選擇需要使用的型別

更具具體的業務需要使用索引，專案書記大了之後速度也就上來了

持續更新

mysql8.0 innodb 儲存引擎介紹 加倆類索引方法 btree hash ，三類索引型別 Normal Unique Full Text 業務應用中選擇思路，及官方各類儲存引擎對服務支援情況

1.介紹

2.使用InnoDB表的好處

2.1恢復-具體怎麼恢復有這麼幾種型別：