mysql> alter table t111 engine=innodb;
mysql> show create table t111;  
注意修改表的引擎同时会有清理碎片的功能，但是会有短时间锁表，建议凌晨数据量小的时候操作
mysql> alter table t111 engine=innodb;

alter table zabbix.a  engine=tokudb;
select concat("alter table ",table_schema,".",table_name,"  engine=tokudb;") from information_schema.tables 
where table_schema=‘zabbix‘;

ibdata1：系统数据字典信息(统计信息)，UNDO表空间等数据
ib_logfile0 ~ ib_logfile1: REDO日志文件，事务日志文件。
ibtmp1： 临时表空间磁盘位置，存储临时表
frm：存储表的列信息
ibd：表的数据行和索引

ibdata1 : 整个库的统计信息+Undo   
ibd	    : 数据行和索引

1. 5.5 版本的默认模式,5.6中转换为了独立表空间 
需要将所有数据存储到同一个表空间中 ，管理比较混乱
2. 5.5版本出现的管理模式，也是默认的管理模式。
3. 5.6版本以，共享表空间保留，只用来存储:数据字典信息,undo,临时表。
4. 5.7 版本,临时表被独立出来了
5. 8.0版本,undo也被独立出去了
具体变化参考官方文档:
https://dev.mysql.com/doc/refman/5.6/en/innodb-architecture.html
https://dev.mysql.com/doc/refman/5.7/en/innodb-architecture.html
https://dev.mysql.com/doc/refman/5.8/en/innodb-architecture.html

[(none)]>select @@innodb_data_file_path;
[(none)]>show variables like ‘%extend%‘;
innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend
innodb_autoextend_increment=64
注意，设置的时候需要在初始化之前在/etc/my.cnf上添加如下设置，然后再进行初始化：
innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend
mysqld --initialize-insecure --user=mysql --basedir=xxxxxx......

从5.6，默认表空间不再使用共享表空间，替换为独立表空间。
主要存储的是用户数据
存储特点为：一个表一个ibd文件，存储数据行和索引信息
基本表结构元数据存储：
xxx.frm
最终结论：
      元数据            数据行+索引
mysql表数据    =（ibdataX+frm）+ibd(段、区、页)
        DDL             DML+DQL

MySQL的存储引擎日志：
Redo Log: ib_logfile0  ib_logfile1，重做日志
Undo Log: ibdata1 ibdata2(存储在共享表空间中)，回滚日志
临时表:ibtmp1，在做join union操作产生临时数据，用完就自动

一张InnoDB表= frm+idb+ibdata1 
MySQL的存储引擎日志：
Redo Log: ib_logfile0  ib_logfile1，重做日志
Undo Log: ibdata1 ibdata2(存储在共享表空间中)，回滚日志
临时表:ibtmp1，在做join union操作产生临时数据，用完就自动清理

mysql> select @@innodb_file_per_table;
+-------------------------+
| @@innodb_file_per_table |
+-------------------------+
|                       1 |
+-------------------------+
1 row in set (0.00 sec)

(1)创建和原表结构一致的空表
(2)将空表的ibd文件删除
alter table city dicard tablespace;
(3)将原表的ibd拷贝过来,并且修改权限
(4)将原表ibd进行导入
alter table city import tablespace;

1. 在旧的数据库中找到t100w的建表语句
mysql> show create table t100w;
2. 在新的的MySQL创建一个库以及原来相同的结构的表
mysql> CREATE TABLE `t100w` (... ...)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
3. 将空表中的ibd文件删除
mysql> alter table t100w discard tablespace;
4. 将原表的ibd文件拷贝过来，并注意权限
  [root@test02 test01]# cp -a /data/3307/data/test01/t100w.ibd .
 5. 将原表的ibd文件进行导入
    mysql> alter table t100w import tablespace;  
Query OK, 0 rows affected, 1 warning (0.72 sec)
mysql> select count(*) from t100w;
+----------+
| count(*) |
+----------+
|  1030345 |
+----------+

A代表Atomic（原子性）
所有语句作为一个单元全部成功执行或全部取消。不能出现中间状态。

C代表Consistent（一致性）
如果数据库在事务开始时处于一致状态，则在执行该事务期间将保留一致状态。

I代表Isolated（隔离性）
事务之间不相互影响。

Durable（持久性）
事务成功完成后，所做的所有更改都会准确地记录在数据库中。所做的更改不会丢失。

开启事务一般执行begin，就开始一个事务，commit就提交一个事务，但是5.7版本的的begin可以省略
begin ;

DML : 
insert  
update  
delete
mysql> use world;
mysql> update city set countrycode=‘CHN‘ where id=1;
mysql> update city set countrycode=‘CHN‘ where id=2;
mysql> update city set countrycode=‘CHN‘ where id=3;

提交:
commit;
回滚:
rollback;

mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            1 |
+--------------+

(1) 会话级别:  
mysql> set autocommit=0;
及时生效,只影响当前登录会话
(2)全局级别:
mysql> set global autocommit=0;  
断开窗口重连后生效,影响到所有新开的会话

vim /etc/my.cnf 
autocommit=0

begin 
a
b
create database
导致提交的非事务语句：
DDL语句： （ALTER、CREATE 和 DROP）
DCL语句： （GRANT、REVOKE 和 SET PASSWORD）
锁定语句：（LOCK TABLES 和 UNLOCK TABLES）
导致隐式提交的语句示例：
TRUNCATE TABLE
LOAD DATA INFILE
SELECT FOR UPDATE

1. redo log: 重做日志
ib_logfile0~1   默认50M  , 轮询使用

2. redo log buffer :
redo内存区域,redo缓存
ibd   :
存储 数据行和索引 

3. data buffer pool :
缓冲区池,数据和索引的缓冲

4. LSN : 日志序列号 ，含有LSN的组件包含如下：
ibd ,redolog ,data buffer pool, redo buffer
MySQL 每次数据库启动,都会比较磁盘数据页和redolog的LSN,必须要求两者LSN一致数据库才能正常启动

4. WAL (持久化):
write ahead log 日志优先写的方式实现持久化
日志是优先于数据写入磁盘的.

5. 脏页: 
内存脏页,内存中发生了修改,没写入到磁盘之前,我们把内存页称之为脏页.

6. CKPT:
Checkpoint,检查点,就是将脏页刷写到磁盘的动作

7. TXID: 
事务号,InnoDB会为每一个事务生成一个事务号,伴随着整个事务.

(1)记录了内存数据页的变化.
(2)提供快速的持久化功能(WAL)
(3)CSR过程中实现前滚的操作(磁盘数据页和redo日志LSN一致)

redo的日志文件：iblogfile0 iblogfile1

(1)记录了数据修改之前的状态
(2)rollback 将内存的数据修改恢复到修改之前
(3)在CSR中实现未提交数据的回滚操作
(4)实现一致性快照,配合隔离级别保证MVCC,读和写的操作不会互相阻塞

row-level lock 
gap 
next-lock

隔离级别参数：transaction_isolation
mysql> select @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ         |
+-------------------------+
RU  : 读未提交,可脏读,一般部议叙出现
RC  : 读已提交,可能出现幻读,可以防止脏读.
RR  : 可重复读,功能是防止"幻读"现象 ,利用的是undo的快照技术+GAP(间隙锁)+NextLock(下键锁)
SR   : 可串行化,可以防止死锁,但是并发事务性能较差
补充: 在RC级别下,可以减轻GAP+NextLock锁的问题,但是会出现幻读现象,一般在为了读一致性会在正常select后添加for update语句.但是,请记住执行完一定要commit 否则容易出现所等待比较严重.

transaction_isolation=read-uncommitted
transaction_isolation=read-committed
transaction_isolation=REPEATABLE-READ
MVCC   --->   undo 快照

show engines;
show variables like ‘default_storage_engine‘;
select @@default_storage_engine;
(1) 通过参数设置默认引擎
(2) 建表的时候进行设置
(3) alter table t1 engine=innodb

innodb_data_file_path
一般是在初始化数据之前就设置好
例子:
innodb_data_file_path=ibdata1:512M:ibdata2:512M:autoextend

show variables like ‘innodb_file_per_table‘;

select @@innodb_buffer_pool_size;
show engine innodb status\G
innodb_buffer_pool_size 
一般建议最多是物理内存的 75-80%

select @@innodb_flush_log_at_trx_commit;

1，每次事物的提交都会引起日志文件写入、flush磁盘的操作，确保了事务的ACID；flush到操作系统的文件系统缓存  fsync到物理磁盘.
0，表示当事务提交时，不做日志写入操作，而是每秒钟将log buffer中的数据写入文件系统缓存并且秒fsync磁盘一次；
2，每次事务提交引起写入文件系统缓存,但每秒钟完成一次fsync磁盘操作。
--------
The default setting of 1 is required for full ACID compliance. Logs are written and flushed to disk at each transaction commit.
With a setting of 0, logs are written and flushed to disk once per second. Transactions for which logs have not been flushed can be lost in a crash.
With a setting of 2, logs are written after each transaction commit and flushed to disk once per second. Transactions for which logs have not been flushed can be lost in a crash.
-------

控制的是,log buffer 和data buffer,刷写磁盘的时候是否经过文件系统缓存

show variables like ‘%innodb_flush%‘;

O_DIRECT  :数据缓冲区写磁盘,不走OS buffer
fsync :日志和数据缓冲区写磁盘,都走OS buffer
O_DSYNC  :日志缓冲区写磁盘,不走 OS buffer

最高安全模式
innodb_flush_log_at_trx_commit=1
Innodb_flush_method=O_DIRECT
最高性能:
innodb_flush_log_at_trx_commit=0
Innodb_flush_method=fsync

innodb_log_buffer_size=16777216
innodb_log_file_size=50331648
innodb_log_files_in_group = 3

RR模式(对索引进行删除时):
GAP:          间隙锁
next-lock:    下一键锁定

例子:
id（有索引）
1 2 3 4 5 6 
GAP：
在对3这个值做变更时，会产生两种锁，一种是本行的行级锁，另一种会在2和4索引键上进行枷锁
next-lock：
对第六行变更时，一种是本行的行级锁，在索引末尾键进行加锁，6以后的值在这时是不能被插入的。
总之：
GAP、next lock都是为了保证RR模式下，不会出现幻读，降低隔离级别或取消索引，这两种锁都不会产生。