在行中,默认有两个隐藏字段:
MySQL5.5 版本开始,默认使用InnoDB存储引擎,它擅长事务处理,具有崩溃恢复特性,在日常开发中使用非常广泛。下面是InnoDB架构图,左侧为内存结构,右侧为磁盘结构。
内存结构主要分为: Buffer Pool、Change Buffer、Adaptive Hash Index、Log Buffer。
缓冲池 Buffer Pool
InnoDB存储引擎基于磁盘文件存储,物理硬盘和内存中访问速度相差很大,为了尽可能弥补这两者之间的I/O效率的差值,就需要把经常使用的数据加载到缓冲池中,避免每次访问都进行磁盘I/O。在InnoDB的缓冲池中不仅缓存了索引页和数据页,还包含了undo页、插入缓存、自适应哈希索引以及InnoDB的锁信息等等。
缓冲池 Buffer Pool是主内存中的一个区域,可以缓存磁盘上经常操作的真实数据,在执行增删改查操作时,先操作缓冲池中的数据(若缓冲池没有数据,则从磁盘加载并缓存),再以一定频率将缓冲池中的数据刷到磁盘中,从而减少磁盘IO,加快处理速度。
缓冲池以Page页为单位,底层采用链表数据结构管理Page。根据状态Page分为三种类型:
在专用服务器上,通常将多达80%的物理内存分配给缓冲池 。参数设置: show variables like ‘innodb_buffer_pool_size’;
更改缓冲区Change Buffer
Change Buffer,更改缓冲区(针对于非唯一的二级索引页),在执行DML语句时,如果这些数据页不在Buffer Pool中,不会直接操作磁盘,而会将数据变更存缓存在更改缓冲区 Change Buffer中,在将来数据被读取时,再将数据合并恢复到Buffer Pool中,再将合并后的数据刷新到磁盘中。(主键索引和唯一索引不会操作更改缓冲区)
Change Buffer的意义是什么呢?
二级索引的结构图如下:与聚集索引不同,二级索引通常是非唯一的,并且以相对随机的顺序插入二级索引。所以每次删除和更新都可能会影响索引树中不相邻的二级索引页,如果每一次都操作磁盘,会造成大量的磁盘IO。有了ChangeBuffer之后,可以在缓冲池中进行合并处理,减少磁盘IO,提高了效率。
自适应hash索引Adaptive Hash Index
hash索引在不存在hash冲突的情况下只需要一次匹配,效率高,对应B+树,可能需要进行几次匹配,但是hash索引不适合做范围查询、模糊匹配,只适合做等值匹配。MySQL的innoDB引擎中没有直接支持hash索引,但是提供了一自适应hash索引,用于优化对Buffer Pool数据的查询。
InnoDB存储引擎会监控对表上各索引页的查询,如果观察到在特定的条件下hash索引可以提升速度,则自动建立hash索引,称之为自适应hash索引。
自适应哈希索引,无需人工干预,是系统根据情况自动完成。
查看是否开启: show variables ‘%hash_index%’; ON开启
日志缓冲区Log Buffer
Log Buffer:日志缓冲区,用来保存要写入到磁盘中的log日志数据(redo log 、undo log),默认大小为 16MB,日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事务,增加日志缓冲区的大小可以节省磁盘 I/O。
参数:innodb_log_buffer_size:缓冲区大小
innodb_flush_log_at_trx_commit:日志刷新到磁盘时机,取值主要包含以下三个:
系统表空间System Tablespace
系统表空间是更改缓冲区的存储区域。如果InnoDB引擎当中每一张表的独立表空间关闭时,所有表的数据和索引都会存储在系统表空间。(在MySQL5.x版本中还包含InnoDB数据字典、undolog等)
参数:innodb_data_file_path,系统表空间,默认的文件名叫 ibdata1。
独立表空间File-Per-Table Tablespaces
每张表的独立表空间包含单个InnoDB表的数据和索引,并存储在文件系统上的单个数据文件中。
开关参数:innodb_file_per_table ,该参数默认开启。
即每创建一个表,都会产生一个表空间文件,如图:
通用表空间General Tablespaces
通用表空间,需要手动创建,在创建表时,可以指定该表空间。
## 创建表空间
CREATE TABLESPACE ts_name ADD DATAFILE 'file_name' ENGINE = engine_name;
## 创建表时指定表空间
CREATE TABLE xxx ... TABLESPACE ts_name;
撤销表空间Undo Tablespaces
MySQL实例在初始化时会自动创建两个默认的undo表空间(初始大小16M),用于存储undo log日志。
临时表空间Temporary Tablespaces
InnoDB 使用会话临时表空间和全局临时表空间。存储用户创建的临时表等数据。
双写缓冲区Doublewrite Buffer Files
innoDB引擎将数据页从Buffer Pool刷新到磁盘前,为了保证数据的安全性,先将数据页写入双写缓冲区文件中,便于系统异常时恢复数据。
重做日志Redo Log
重做日志用来实现事务的持久性。包含重做日志缓冲(redo logbuffer)和重做日志文件(redo log),前者是在内存中,后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中, 用于在刷新脏页到磁盘时,发生错误时, 进行数据恢复使用。Redo Log不会永久保存,会每隔一段时间清理之前没用的Redo Log,当事务提交之后,就没用了,主要是保证异常时数据恢复,从而保证事务的持久性。
后台线程
内存结构中的数据刷新到磁盘结构中,就需要借助后台线程:
在InnoDB的后台线程分为4类:Master Thread 、IO Thread、Purge Thread、Page Cleaner Thread。
Master Thread
核心后台线程,负责调度其他线程,还负责将缓冲池中的数据异步刷新到磁盘中, 保持数据的一致性,还包括脏页的刷新、合并插入缓存、undo页的回收 。
IO Thread
在InnoDB存储引擎中大量使用了AIO(异步非阻塞IO)来处理IO请求, 这样可以极大地提高数据库的性能,而IOThread主要负责这些IO请求的回调。
通过以下的这条指令,查看到InnoDB的状态信息,其中就包含IO Thread信息。
show engine innodb status \G;
Purge Thread
主要用于回收事务已经提交了的undo log,在事务提交之后,undo log可能不用了,就用它来回收。
Page Cleaner Thread
协助 Master Thread 刷新脏页到磁盘的线程,它可以减轻 Master Thread 的工作压力,减少阻塞。
事务是一组操作的集合,它是一个不可分割的工作单位,事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求,即这些操作要么同时成功,要么同时失败。
原子性、一致性、持久化,实际上是由InnoDB中的两份日志来保证的,一份是redo log日志,一份是undo log日志。持久性是通过数据库的锁,加上MVCC来保证的。
重做日志redo log,记录的是事务提交时数据页的物理修改,来实现事务的持久性。
该日志文件由两部分组成:重做日志缓冲(redo log buffer)以及重做日志文件(redo log file),前者是在内存中,后者在磁盘中。当事务提交之后会把所有修改信息都存到重做日志文件中, 用于在刷新脏页到磁盘,发生错误时, 进行数据恢复使用,从而保证事务的持久性
如果没有redolog,可能会存在什么问题的?
1.在InnoDB引擎中的内存结构中,主要的内存区域就是缓冲池,在缓冲池中缓存了很多的数据页。
2. 当一个事务执行多个增删改的操作时,InnoDB引擎会先操作缓冲池中的数据,如果缓冲区没有对应的数据,会通过后台线程将磁盘中的数据加载出来,存放在缓冲区中。
3.然后将缓冲池中的数据修改(磁盘的数据还未修改),修改后的数据页称为脏页。
4.脏页会在一定的时机,通过后台线程刷新到磁盘中,从而保证缓冲区与磁盘的数据一致。
5. 缓冲区的脏页数据并不是实时刷新的,而是一段时间之后将缓冲区的数据刷新到磁盘中,假如刷新到磁盘的过程出错了,而提示给用户事务提交成功,而数据却没有持久化下来,没有保证事务的持久性。
在InnoDB中提供了一份日志 redo log,通过redolog如何解决这个问题。
1.对缓冲区的数据进行增删改之后,首先会将操作的数据页的变化,记录在redolog buffer中。
2.在事务提交时,会将redo log buffer中的数据刷新到redo log磁盘文件中。
3.过一段时间后,如果刷新缓冲区的脏页到磁盘时,发生错误,此时就可以借助于redo log进行数据恢复,这样就保证了事务的持久性。
4.如果脏页成功刷新到磁盘或者涉及到的数据已经落盘,此时redolog就没有作用了,就可以删除了,所以存在的两个redolog文件是循环写的。
为什么每一次提交事务,要刷新redo log 到磁盘中呢,而不是直接将buffer pool中的脏页刷新到磁盘呢 ?
在业务操作中,操作数据一般都是随机读写磁盘的,而不是顺序读写磁盘。 涉及大量磁盘IO性能是比较低的,而redo log在往磁盘文件中写入数据,由于是日志文件,都是追加的,所以都是顺序写的。顺序写的效率,要远大于随机写。 这种先写日志的方式,称之为 WAL(Write-Ahead Logging)。写入日志之后,过一段时间再将脏页的数据刷新到磁盘当中。
回滚日志undolog,用于记录数据被修改前的信息 , 作用包含两个 : 提供回滚(保证事务的原子性) 和MVCC(多版本并发控制) ,保证事务的原子性。
undo log和redo log记录物理日志(数据内容是什么),它是逻辑日志(每一步执行什么样的操作)。可以认为当delete一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当update一条记录时,它记录一条对应相反的update记录(执行update数据之前,数据的样子)。当执行rollback时,就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
Undo log销毁: undo log在事务执行时产生,事务提交时,并不会立即删除undo log,因为这些日志可能还用于MVCC。
Undo log存储: undo log采用段的方式进行管理和记录,存放在前面介绍的 rollback segment回滚段中,内部包含1024个undo log segment。
当前读: 读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。对于我们日常的操作,如:select … lock in share mode(共享锁),select …for update、update、insert、delete(排他锁)都是一种当前读。
在测试中我们可以看到,即使是在默认的RR(可重复读)隔离级别下,事务A中依然可以读取到事务B最新提交的内容,因为在查询语句后面加上了 lock in share mode 共享锁,此时是当前读操作。当我们加排他锁的时候,也是当前读操作。
快照读: 简单的select(不加锁)就是快照读,快照读,读取的是记录数据的可见版本,有可能是历史数据,不加锁,是非阻塞读。
即使事务B提交了数据,事务A中也查询不到。 因为普通的select是快照读,而在当前默认的RR隔离级别下,开启事务后第一个select语句才是快照读的地方,后面执行相同的select语句都是从快照中获取数据,可能不是当前的最新数据,这样也就保证了可重复读。
MVCC:全称 Multi-Version Concurrency Control,多版本并发控制。 指维护一个数据的多个版本,使得读写操作没有冲突,快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现,还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。
MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。而MVCC + 锁,则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证。
当我们创建了上面的这张表,我们在查看表结构的时候,就可以显式的看到这三个字段。 实际上除了这三个字段以外,InnoDB还会自动的给我们添加三个隐藏字段及其含义分别是:
而上述的前两个字段是肯定会添加的, 是否添加最后一个字段DB_ROW_ID,得看当前表有没有主键,如果有主键,则不会添加该隐藏字段。
查看有主键的表 stu,进入服务器中的 /var/lib/mysql/itcast/ , 查看stu的表结构信息, 通过如下指令:
ibd2sdi stu.ibd
查看到的表结构信息中,有一栏 columns,在其中我们会看到处理我们建表时指定的字段以外,还有额外的两个字段 分别是:DB_TRX_ID 、 DB_ROLL_PTR ,因为该表有主键,所以没有DB_ROW_ID隐藏字段。
查看没有主键的表 employee,建表语句:
create table employee (id int , name varchar(10));
再通过以下指令来查看表结构及其其中的字段信息:
ibd2sdi employee.ibd
查看到的表结构信息中,有一栏 columns,除了建表时指定的字段以外,还有额外的三个字段 分别是:DB_TRX_ID 、 DB_ROLL_PTR 、DB_ROW_ID,因为employee表是没有指定主键的。
回滚日志,在insert、update、delete的时候产生的便于数据回滚的日志。
当insert的时候,产生的undo log日志只在回滚时需要,在事务提交后,可被立即删除。
而update、delete的时候,产生的undo log日志不仅在回滚时需要,在快照读时也需要,不会立即被删除。
DB_TRX_ID : 代表最近修改事务ID,记录插入这条记录或最后一次修改该记录的事务ID,是自增的。
DB_ROLL_PTR : 由于这条数据是才插入的,没有被更新过,所以该字段值为null。
在并发访问下,有四个并发事务同时在访问这张表:
当事务2执行第一条修改语句时,将数据变更之前的数据记录在undo log日志,再执行更新操作,DB_TRX_ID记录本次操作的事务ID(记录哪个事务最后操作这条数据),当前事务id为2,DB_ROLL_PTR 回滚指针,回滚指针用来指定如果发生回滚,回滚到哪一个版本。
当事务3执行第一条修改语句时,也会记录undo log日志,如上。
当事务4执行第一条修改语句时,也会记录undo log日志,如上。
不同事务或相同事务对同一条记录进行修改,会导致该记录的undolog生成一条记录版本链表,链表的头部是最新的旧记录,链表尾部是最早的旧记录。
ReadView(读视图)是快照读 SQL执行时MVCC提取数据的依据,记录并维护系统当前活跃的事务(未提交的)id。
而在readview中就规定了版本链数据的访问规则:trx_id 代表当前undolog版本链对应事务ID。
不同的隔离级别,生成ReadView的时机不同:
在事务5中,查询了两次id为30的记录,由于隔离级别为Read Committed,所以每一次进行快照读都会生成一个ReadView,两次生成的ReadView如下:
在进行匹配时,会从undo log的版本链中,从上到下进行挨个匹配
第一次快照读具体的读取过程:
1.先匹配trx_id=4这条记录,将4代入右侧的匹配规则中,①不满足 ②不满足 ③不满足 ④也不满足 ,都不满足,则继续匹配undo log版本链的下一条。
2.再匹配trx_id为3这条记录,代入右侧的匹配规则中。①不满足 ②不满足 ③不满足 ④也不满足 ,都不满足,则继续匹配undo log版本链的下一条。
3.trx_id为2这条记录,将2带入右侧的匹配规则中。①不满足 ②满足 终止匹配,此次快照读,返回的数据就是版本链中记录的这条数据。
第二次快照读具体的读取过程:
1.匹配trx_id为4的记录,将4带入右侧的匹配规则中。 ①不满足 ②不满足 ③不满足 ④也不满足 ,都不满足,则继续匹配undo log版本链的下一条。
2.匹配trx_id为3的记录,将3带入右侧的匹配规则中。①不满足 ②满足 。终止匹配,此次快照读,返回的数据就是版本链中记录的这条数据。
RR隔离级别下,仅在事务中第一次执行快照读时生成ReadView,后续复用该ReadView。 而RR 是可重复读,在一个事务中,执行两次相同的select语句,查询到的结果是一样的。
在RR隔离级别下,只是在事务中第一次快照读时生成ReadView,后续都是复用该ReadView,那么既然ReadView都一样, ReadView的版本链匹配规则也一样, 那么最终快照读返回的结果也是一样的。
Mysql数据库安装完成后,自带了一下四个数据库,具体作用如下:
mysql: 该mysql不是指mysql服务,而是指mysql的客户端工具
语法 :
mysql [options] [database]
选项 :
-u, --user=name #指定用户名
-p, --password[=name] #指定密码
-h, --host=name #指定服务器IP或域名
-P, --port=port #指定连接端口
-e, --execute=name #执行SQL语句并退出
-e选项可以在Mysql客户端执行SQL语句,而不用连接到MySQL数据库再执行,对于一些批处理脚本,这种方式尤其方便。
示例:
mysql -uroot –p123456 db01 -e "select * from stu";
mysqladmin: 是一个执行管理操作的客户端程序。可以用它来检查服务器的配置和当前状态、创建并删除数据库等。
通过帮助文档查看选项:
mysqladmin --help
语法:
mysqladmin [options] command ...
选项:
-u, --user=name #指定用户名
-p, --password[=name] #指定密码
-h, --host=name #指定服务器IP或域名
-P, --port=port #指定连接端口
示例:
mysqladmin -uroot –p1234 drop 'test01';
mysqladmin -uroot –p1234 version;
mysqlbinlog: 由于服务器生成的二进制日志文件以二进制格式保存,所以如果想要检查这些文本的文本格式,就会使用到mysqlbinlog 日志管理工具。
语法 :
mysqlbinlog [options] log-files1 log-files2 ...
选项 :
-d, --database=name 指定数据库名称,只列出指定的数据库相关操作。
-o, --offset=# 忽略掉日志中的前n行命令。
-r,--result-file=name 将输出的文本格式日志输出到指定文件。
-s, --short-form 显示简单格式, 省略掉一些信息。
--start-datatime=date1 --stop-datetime=date2 指定日期间隔内的所有日志。
--start-position=pos1 --stop-position=pos2 指定位置间隔内的所有日志。
mysqlshow: 客户端对象查找工具,用来很快地查找存在哪些数据库、数据库中的表、表中的列或者索引。
语法 :
mysqlshow [options] [db_name [table_name [col_name]]]
选项 :
--count 显示数据库及表的统计信息(数据库,表 均可以不指定)
-i 显示指定数据库或者指定表的状态信息
示例:
#查询test库中每个表中的字段书,及行数
mysqlshow -uroot -p2143 test --count
#查询test库中book表的详细情况
mysqlshow -uroot -p2143 test book --count
示例: 查询每个数据库的表的数量及表中记录的数量
mysqlshow -uroot -p1234 --count
示例:查看数据库hei的统计信息
mysqlshow -uroot -p1234 heimam --count
示例:查看数据库heima中的stu表的信息
mysqlshow -uroot -p1234 heima stu --count
mysqlshow -uroot -p1234 heima stu id --count
mysqldump: 客户端工具用来备份数据库或在不同数据库之间进行数据迁移。备份内容包含创建表,及插入表的SQL语句。
语法 :
mysqldump [options] db_name [tables]
mysqldump [options] --database/-B db1 [db2 db3...]
mysqldump [options] --all-databases/-A
连接选项 :
-u, --user=name 指定用户名
-p, --password[=name] 指定密码
-h, --host=name 指定服务器ip或域名
-P, --port=# 指定连接端口
输出选项:
--add-drop-database 在每个数据库创建语句前加上 drop database 语句
--add-drop-table 在每个表创建语句前加上 drop table 语句 , 默认开启 ; 不开启 (--skip-add-drop-table)
-n, --no-create-db 不包含数据库的创建语句
-t, --no-create-info 不包含数据表的创建语句
-d --no-data 不包含数据
-T, --tab=name 自动生成两个文件:一个.sql文件,创建表结构的语句;一个.txt文件,数据文件
示例:备份db01数据库:
mysqldump -uroot -p12345678 heima > heima.sql
可以直接打开db01.sql,来查看备份出来的数据到底什么样。
备份出来的数据包含:删除表的语句,创建表的语句,数据插入语句
在数据备份时,不需要创建表,或者不需要备份数据,只需要备份表结构,都可以通过对应的参数来实现。
备份db01数据库中的表数据,不备份表结构(-t)
mysqldump -uroot -p12345678 -t heima > heima02.sql
打开 heima02.sql ,来查看备份的数据,只有insert语句,没有备份表结构。
只备份表结构,不备份数据
mysqldump -uroot -p12345678 -d heima > heima03.sql
mysqldump -uroot -p1234 -T /root db01 score
执行上述指令会出错,数据不能完成备份,因为所指定的数据存放目录/root,MySQL认为是不安全的,需要存储在MySQL信任的目录下。可以查看一下系统变量 secure_file_priv ,查看信任目录,执行结果如下:
上述的两个文件 score.sql 中记录的就是表结构文件,而 score.txt 就是表数据文件,但是需要注意表数据文件,并不是记录一条条的insert语句,而是按照一定的格式记录表结构中的数据。如下:
mysqlimport: 是客户端数据导入工具,导入备份的txt文件,用来导入mysqldump 加 -T 参数后导出的文本文件。
语法 :
mysqlimport [options] db_name textfile1 [textfile2...]
示例 :
mysqlimport -uroot -p2143 test /tmp/city.txt
出现问题:不信任的目录,默认是当前目录,需要加上目录路径。
source: 导入备份的sql文件
source /root/xxxxx.sql