mysql存儲引擎、事務

MySQL存儲引擎介紹

文件系統

• 操做系統組織和存取數據的一種機制。
• 文件系統是一種軟件。

文件系統類型

ext2  ext3  ext4  xfs 數據

無論使用什麼文件系統，數據內容不會變化

不一樣的是，存儲空間、大小、速度

MySQL引擎

能夠將MySQL引擎理解爲：MySQL的「文件系統」，只不過功能更增強大。

MySQL引擎的功能

除了能夠提供基本的存取功能，還有更多功能事務功能、鎖定、備份和恢復、優化以及特殊功能。

MySQL 提供如下存儲引擎：

– InnoDB
– MyISAM
– MEMORY
– ARCHIVE
– FEDERATED
– EXAMPLE
– BLACKHOLE
– MERGE
– NDBCLUSTER
– CSV

注：只有innodb與myisam最經常使用

Innodb存儲引擎簡介

在MySQL5.5版本以後，默認的存儲引擎，提供高可靠性和高性能。

Innodb引擎的優勢

1. 事務安全（聽從ACID）
2. MVCC（Multi-Versioning Concurrency Control，多版本併發控制）：InnoDB行級鎖、Oracle樣式一致非鎖定讀取(共享鎖)
3. 表數據進行整理來優化基於主鍵的查詢（彙集索引）
4. 支持外鍵引用完整性約束
5. 大型數據捲上的最大性能
6. 將對錶的查詢與不一樣存儲引擎混合
7. 出現故障後快速自動恢復（crash safe recovery）
8. 用於在內存中緩存數據和索引的緩衝區池（buffer pool（data buffer page  log buffer page） 、undo buffer page）

查看數據庫的存儲引擎設置

使用SELECT確認會話存儲引擎：

SELECT @@default_storage_engine;
show variables like '%engine%';

使用SHOW確認每一個表的存儲引擎：

SHOW CREATE TABLE City\G
SHOW TABLE STATUS LIKE 'CountryLanguage'\G

使用INFORMATION_SCHEMA確認每一個表的存儲引擎：

SELECT TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'City' AND TABLE_SCHEMA = 'world'\G

設置存儲引擎

基本不須要修改設置存儲引擎

在啓動配置文件中設置服務器存儲引擎：

[mysqld] 
default-storage-engine=<Storage Engine>

使用 SET 命令爲當前客戶機會話設置：

SET @@storage_engine=<Storage Engine>;

在CREATE TABLE 語句指定：

CREATE TABLE t (i INT) ENGINE = <Storage Engine>;

從5.1版本遷移到5.5以上版本的mysql注意修改存儲引擎

假如5.1全部生產表都是myisam的

使用mysqldump備份後，必定要替換備份的文件中的engine字段從myisam到innodb

不然遷移就沒有意義

Innodb體系結構

物理存儲結構（表空間）：　

 

InnoDB 系統表空間

默認狀況下，InnoDB 元數據、撤消日誌和緩衝區存儲在系統「表空間」中

表空間：MySQL數據庫存儲的方式

表空間中包含數據文件

MySQL表空間和數據文件是1:1的關係

共享表空間除外，是能夠1:N關係

表空間類型

一、共享表空間：ibdata1~ibdataN,通常是2-3個

二、獨立表空間：存放在指定庫目錄下

例如data/world/目錄下的city.ibd 表空間位置（datadir）：data/目錄下

系統表空間的存儲內容

共享表空間的物理存儲結構（ibdata1~N），也一般被叫作系統表空間，是數據庫初始化生成的。

一、系統元數據，基表數據，除了表內容數據以外的數據

二、undo日誌（回滾日誌）數據

三、tmp表空間（通常不多關注）

　　ib_logfile0~N（redo日誌）

　　存放的是innodb表的重作日誌。

　　註釋：

　　undo日誌默認是在ibdata中的，在5.6之後是能夠單獨定義的。

　　tmp表空間在5.7版本之後也被移出了ibdata1，ibtmp1

　　在5.5版本之前，全部的應用數據也都默認存放到了ibdata中

數據獨立表空間

除了系統表空間以外，InnoDB 還在數據庫目錄中建立另外的表空間，用於每一個 InnoDB 表的 .ibd 文件。

InnoDB 建立的每一個新表在數據庫目錄中設置一個 .ibd 文件來搭配表的 .frm 文件。

在5.6之後，默認的狀況下，會單表單獨存儲到獨立表空間文件中。

獨立表空間設置：

show variables like '%per_table%';

在參數文件/etc/my.cnf能夠控制獨立表空間功能是否開啓，5.6默認開啓的。

innodb_file_per_table=1   ---->開啓獨立表空間，單表單存儲
innodb_file_per_table=0   ---->關閉獨立表空間，全部數據存放到ibdata中

設置共享表空間

經過添加數據文件增長表空間大小。

在 my.cnf 文件中使用 innodb_data_file_path 選項

[mysqld]
innodb_data_file_path=datafile_spec1[;datafile_spec2]

配置共享表空間實例

配置示例：建立一個表空間，其中包含一個名爲 ibdata1 且大小爲 12 MB （固定）的數據文件和一個名爲 ibdata2 且大小爲 100 MB（自動擴展）的數據文件：

通常是在初始搭建環境的時候就定義好，通常2-3個共享表空間文件

預設值1G，最後一個文件自動擴展

vi /etc/my.cnf
innodb_data_file_path=ibdata1:12M;ibdata2:100M:autoextend

默認狀況下將文件放置在 data 目錄中。

若是須要，顯式指定文件位置。

 Innodb引擎、事務

事務生命週期圖

 

 事務ACID

A --- Atomic（原子性）

全部語句做爲一個單元所有成功執行或所有取消。

例如：

update  t1 set  money=10000-17      where id=我的微信號
update   t1  set  money=1000000+17  where id=二連長的微信號
以上語句都成功了，才能把產品給你

C --- Consistent（一致性）

若是數據庫在事務開始時處於一致狀態，則在執行該事務期間將保留一致狀態。

例如：

update  t1 set  money=10000-17       where id=我的微信號
update   t1  set  money=1000000+17   where id=二連長的微信號
在以上操做過程沒有徹底成功狀況下，你去查本身的帳戶，應該仍是10000塊

I --- Isolated（隔離性）

事務之間不相互影響。

例如：

update  t1 set  money=10000-17       where id=我的微信號
update   t1  set  money=1000000+17  where id=二連長的微信號
1、在作以上操做的時候，其餘人是不能對這兩個帳戶作任何的取款，存款操做
2、在不一樣的隔離條件下，可能一致性保證又不同。

隔離級別會影響到一致性。

read-uncommit  作了操做就顯示結果了

read-commit      可能會用的一種級別，

repeatable-read   默認級別，和oracle同樣，

serializable        嚴格模式，通常不用

D --- Durable（持久性）

事務成功完成後，所作的全部更改都會準確地記錄在

數據庫中。所作的更改不會丟失。

事務的控制語句

• START TRANSACTION（或 BEGIN）：顯式開始一個新事務
• SAVEPOINT：分配事務過程當中的一個位置，以供未來引用
• COMMIT：永久記錄當前事務所作的更改
• ROLLBACK：取消當前事務所作的更改
• ROLLBACK TO SAVEPOINT：取消在 savepoint 以後執行的更改
• RELEASE SAVEPOINT：刪除 savepoint 標識符
• SET AUTOCOMMIT：爲當前鏈接禁用或啓用默認autocommit模式

主要：

begin        事務開始的標記
commit       事務成功提交的標記
rollback     事務回滾的標記

autocommit 設置，控制是否每條DML語句自動提交，生產中要關掉 autocommit=0；也就是設置爲手工提交事務的模式；

設置爲1，開啓自動提交的優勢：數據安全性好，每次修改都會落地。

缺點：

一、不能進行銀行類的交易事務

二、產生大量的小IO

咱們能夠經過如下命令進行修改關閉（0是關閉，1是開啓）

SET GLOBAL AUTOCOMMIT=0; --- 全部新建會話
SET SESSION AUTOCOMMIT=0; --- 當前會話
SELECT @@AUTOCOMMIT; --- 查看設置結果

咱們也能夠修改配置文件讓其永久生效

vi /etc/my.cnf
[mysqld]
autocommit=0

redo

redo,顧名思義「重作日誌」，是事務日誌的一種。

做用：在事務ACID過程當中，實現的是「D」持久化的做用。

先將數據提取到內存中進行操做，在修改完成後，redo記錄數據變化的過程，就算事務的完成，而後就算是斷電事務沒來的及寫入磁盤，下次開啓數據庫redo也會先執行修改數據。

innodb_flush_log_at_trx_commit  ---- 此參數控制着事務提交的時候刷新redo日誌

mysql> show variables like '%commit%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| autocommit                     | ON    |
| binlog_order_commits           | ON    |
| innodb_api_bk_commit_interval  | 5     |
| innodb_commit_concurrency      | 0     |
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
5 rows in set (0.00 sec)

undo

undo,顧名思義「回滾日誌」，是事務日誌的一種。

做用：在事務ACID過程當中，實現的是「A、C」原子性和一致性的做用。

在將數據提取到內存打算修改數據的時候，undo會將數據沒改的時候作一個快照，而後若是有一方失敗，事務就會返回致原樣。

事務中的鎖

在事務ACID過程當中，「鎖」和「隔離級別」一塊兒來實現「I」隔離性的做用。

四種隔離級別：建議使用REPEATABLE  READ

READ UNCOMMITTED  容許事務查看其餘事務所進行的未提交更改

READ COMMITTED       容許事務查看其餘事務所進行的已提交更改

REPEATABLE READ     確保每一個事務的 SELECT 輸出一致（InnoDB 的默認級別）

SERIALIZABLE              將一個事務的結果與其餘事務徹底隔離